On Mon, Nov 9, 2009 at 10:31 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Nov 7, 2009, at 3:08 AM, Joerg Mayer wrote:
>
>> this is just something that went through my mind yesterday while
>> working
>> on the third patch on the same files and without a chance to commit
>> between the patches. If there is one thing that I don't like (although
>> I do it sometimes) is to do a commit that does several things at once.
>> With git, I could commit each patch (which is done locally) and
>> eventually
>> push all commits to the central repository while maintaing the
>> indivitual
>> character of the commits.
>
> The way I work is that I have multiple "working trees" for various
> projects, with modified versions of various source files.
>
> For Wireshark, I do "svn update" on occasion, resolve the conflicts
> myself, and check the code in when it's "done".
>
> For libpcap and tcpdump, which now use Git, that's not so easy, as I
> don't check in my work until it's "done", and then push it. "git
> pull" gets upset when I've modified files; it doesn't work the way
> "cvs update" and "svn update" work.
>
> I presume "git stash" is one of the tools to be used in this case,
> with a "git stash save" before "git pull" and a "git stash pop"
> after. When I tried that, it appeared to do a local commit of the
> work done so far; if I then do more work and another "git commit",
> will both of those commits get pushed individually, or do they get
> pushed as one single commit to the remote repository? I'd prefer the
> latter, as there's no point in exposing individual checkpoints for
> work I've done in the history on the remote repository.
>
> (Currently, I work around it by diffing my tree, backing out my
> changes, doing a "git pull", and then reapplying my changes. That's
> the Git tool I *really* want, but I don't have time to become a
> porcelain craftsman....)
You shouldnt work in the main branch.
Only use the main branch for pulling and pushing to the main repo.
When you want to work on a patch you should first create temporary
local branch and then do all the changes you want in that branch.
git branch work-patch-abc
git checkout work-patch-abc -f
Once you are happy with the patches you either merge the changes back
into the master branch and push
git checkout master -f
git merge work-patch-abc
git push
or you cherry pick the patches you want
git checkout master -f
git log work-patch-abc (and pick the hash for the patches you want)
git-cherry-pick <hash>
git push
git is different from other systems. To really benefit from it you
should use branches, lots of branches.
(Git is different from other systems also in that branches are fast
and easy to work with, not like some systems where branches are
convoluted, slow and will make your life miserable)