11:42 a.m.
Hi there dvcs users,
I am getting used to using git while working with upstream projects. So
when I try to make a patch available upstream, I encounter the following
problem: I want to make small commits during my work but of course send
the result as a single patch via git format-patch. So what's best:
1. clone upstream, create another local branch, work there, and then
merge that branchs changes via diff?
2. use <UNKNOWN_GIT_COMMAND> to merge those commits into a single one?
3. do not use intermdiate local commits (bad idea)
And the final question: When I got to the point of sending one single
patch and upstream merges it, how can I resync with upstream without
having to clone again?
thanks
christoph
11:52 a.m.
On 03/31/2009 12:42 PM, Christoph Höger wrote:
Hi there dvcs users,
I am getting used to using git while working with upstream projects. So
when I try to make a patch available upstream, I encounter the following
problem: I want to make small commits during my work but of course send
the result as a single patch via git format-patch. So what's best:
1. clone upstream, create another local branch, work there, and then
merge that branchs changes via diff?
2. use<UNKNOWN_GIT_COMMAND> to merge those commits into a single one?
"git-diff from..to" can do that. But srsly, why not send a patch series?
That's the beauty of git.
3. do not use intermdiate local commits (bad idea)
And the final question: When I got to the point of sending one single
patch and upstream merges it, how can I resync with upstream without
having to clone again?
git-rebase typically.
behdad
thanks
christoph
11:57 a.m.
On 03/31/2009 12:52 PM, Behdad Esfahbod wrote:
On 03/31/2009 12:42 PM, Christoph Höger wrote:
> Hi there dvcs users,
>
> I am getting used to using git while working with upstream
> projects. So when I try to make a patch available upstream, I
> encounter the following problem: I want to make small commits
> during my work but of course send the result as a single patch via
> git format-patch. So what's best:
>
> 1. clone upstream, create another local branch, work there, and
> then merge that branchs changes via diff?
>
> 2. use<UNKNOWN_GIT_COMMAND> to merge those commits into a single
> one?
"git-diff from..to" can do that. But srsly, why not send a patch
series? That's the beauty of git.
Well, you might still want to send a patch series, but in a form that's
more clear to readers than the series you actually committed.
--
Peter
I was born not knowing and have had only a little time to
change that here and there.
-- Feynman
6:47 p.m.
On Tue, 31 Mar 2009 12:52:42 -0400, Behdad Esfahbod <behdad(a)behdad.org> wrote:
> I am getting used to using git while working with upstream
projects. So
> when I try to make a patch available upstream, I encounter the following
> problem: I want to make small commits during my work but of course send
> the result as a single patch via git format-patch.
"git-diff from..to" can do that. But srsly, why not send a
patch series?
That's the beauty of git.
That only works if your temporary commits make sense. Otherwise
it's a garbage history which cannot be bisected. But I usually commit
things before lunch. Git has many beauties, one is that commits cost
you nothing. Also, free backups.
> And the final question: When I got to the point of sending one
single
> patch and upstream merges it, how can I resync with upstream without
> having to clone again?
git-rebase typically.
Woa, a cannon against sparrows. Although, if you're a big enthusiast
of branches... But I just clone and pull all the time instead.
-- Pete
11:56 a.m.
On 03/31/2009 12:42 PM, Christoph Höger wrote:
Hi there dvcs users,
I am getting used to using git while working with upstream projects. So
when I try to make a patch available upstream, I encounter the following
problem: I want to make small commits during my work but of course send
the result as a single patch via git format-patch. So what's best:
1. clone upstream, create another local branch, work there, and then
merge that branchs changes via diff?
2. use <UNKNOWN_GIT_COMMAND> to merge those commits into a single one?
git rebase --interactive origin
--
Peter
I was born not knowing and have had only a little time to
change that here and there.
-- Feynman
11:58 a.m.
On Tue, Mar 31, 2009 at 06:42:02PM +0200, Christoph Höger wrote:
Hi there dvcs users,
I am getting used to using git while working with upstream projects. So
when I try to make a patch available upstream, I encounter the following
problem: I want to make small commits during my work but of course send
the result as a single patch via git format-patch. So what's best:
1. clone upstream, create another local branch, work there, and then
merge that branchs changes via diff?
I typically do that. I use branches for all sorts of staging and it's
easy to do a:
$ git diff mybranch | patch -p1
or something similar when you are ready. Then you can post that diff.
2. use <UNKNOWN_GIT_COMMAND> to merge those commits into a single one?
You can also do a:
$ git format-patch -1 mybranch
I think. (I don't use this, so I can't say for sure it will work.)
3. do not use intermdiate local commits (bad idea)
And the final question: When I got to the point of sending one single
patch and upstream merges it, how can I resync with upstream without
having to clone again?
thanks
christoph
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
11:59 a.m.
2009/3/31 Christoph Höger <choeger(a)cs.tu-berlin.de>:
1. clone upstream, create another local branch, work there, and then
merge that branchs changes via diff?
2. use <UNKNOWN_GIT_COMMAND> to merge those commits into a single one?
use
git-merge --squash
This will get merge the changes but will not commit , so that you can
commit all in one go.
3. do not use intermdiate local commits (bad idea)
Kushal
--
http://fedoraproject.org
http://kushaldas.in
6:40 p.m.
On Tue, 31 Mar 2009 18:42:02 +0200, Christoph Höger <choeger(a)cs.tu-berlin.de>
wrote:
I am getting used to using git while working with upstream projects.
So
when I try to make a patch available upstream, I encounter the following
problem: I want to make small commits during my work but of course send
the result as a single patch via git format-patch. So what's best:
I just go the caveman way and do
git diff origin master > ../x.diff
And the final question: When I got to the point of sending one
single
patch and upstream merges it, how can I resync with upstream without
having to clone again?
Sure, I always do git pull. If a conflict occurs, I do this
- Edit conflicts so the code looks good (using git status to remind
what's left, and then vi, /, >>> Enter ).
- make check # just see how I'm doing
- git commit -a
This thing posts this scary message "oh you're committing a MERGE,
the sky is falling!" inside the commit template. Just do :wq
and let it commit
In my experience, git merges pretty well. However, I need to watch
out for an occasional double-patch when upstream rearranges chunks.
In C, all functions look the same with 3-line context.
-- Pete
6:51 p.m.
On Tue, Mar 31, 2009 at 4:40 PM, Pete Zaitcev <zaitcev(a)redhat.com> wrote:
On Tue, 31 Mar 2009 18:42:02 +0200, Christoph Höger
<choeger(a)cs.tu-berlin.de> wrote:
> And the final question: When I got to the point of sending one single
> patch and upstream merges it, how can I resync with upstream without
> having to clone again?
Sure, I always do git pull. If a conflict occurs, I do this
- Edit conflicts so the code looks good (using git status to remind
what's left, and then vi, /, >>> Enter ).
- make check # just see how I'm doing
- git commit -a
This thing posts this scary message "oh you're committing a MERGE,
the sky is falling!" inside the commit template. Just do :wq
and let it commit
In my experience, git merges pretty well. However, I need to watch
out for an occasional double-patch when upstream rearranges chunks.
In C, all functions look the same with 3-line context.
FYI, newer git added a --rebase switch to pull. So, you can do "git
pull --rebase origin", and it will just rebase whatever local commits
you have on top. Of course, you may still have conflicts, and that's
not a good idea if your repo is public.
--
Dan
2:28 a.m.
Christoph Höger wrote:
Hi there dvcs users,
I am getting used to using git while working with upstream projects. So
when I try to make a patch available upstream, I encounter the following
problem: I want to make small commits during my work but of course send
the result as a single patch via git format-patch. So what's best:
1. clone upstream, create another local branch, work there, and then
merge that branchs changes via diff?
2. use <UNKNOWN_GIT_COMMAND> to merge those commits into a single one?
3. do not use intermdiate local commits (bad idea)
And the final question: When I got to the point of sending one single
patch and upstream merges it, how can I resync with upstream without
having to clone again?
Git is a very powerful tool (set) and there are different ways of doing
things. Im my experience it is a good idea to keep the fingers off the
master branch and do everything in local branches (lots of them if
necessary). I use qgit to visualize them so it is easy to see how they look
like. After upstream has commited your changes you can either rebase or
delete your local branch. I try to avoid merges completely and do everything
with rebases.
Before commiting/submitting patches upstream I typically clean them up using
rebase -i and even spliting some of them up (git add -i). This creates a
clean history that allows easier error detection (using git bisect) and
understanding what the patches are about. This is IMHO one of the main
benefits of git over most other VCS, but it requires some extra effort and a
different understanding of what your work is.
Florian
5497
days inactive
5498
days old
9 comments
8 participants
participants (8)
-
Andy Gospodarek -
Behdad Esfahbod -
Christoph Höger -
Dan Nicholson -
Florian Festi -
Kushal Das -
Pete Zaitcev -
Peter Jones