* Re: git pull on Linux/ACPI release tree
From: Martin Langhoff @ 2006-01-09 6:08 UTC (permalink / raw)
To: Brown, Len; +Cc: David S. Miller, torvalds, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A136DD@hdsmsx401.amr.corp.intel.com>
On 1/9/06, Brown, Len <len.brown@intel.com> wrote:
> This is completely insane.
> Do you have any idea what "sometimes has problems merging" means
> in practice? It means the tools are really nifty in the trivial
> case but worse than worthless when you need them the most.
Len,
all I meant was that you will sometimes see conflicts. And in that
case, you are far better off cancelling the rebase and doing a merge,
where you will have to resolve the conflicts by hand.
git-rebase is for when the potential merge is clearly trivial. In any
other case, you do want a proper merge. But in any case, it is easy to
do
git-fetch <upstream> && git-rebase <upstream>
and if it does anything but a very trivial merge, backtrack and do a merge.
In any case, if I have any suspicion that the merge may not be trivial, I do
git-fetch <upstream> && gitk --since=" 1 month ago" upstream master
before deciding on a course of action. Of course, you can merge all
the time. It's whether people care about a readable/useful history
afterwards.
cheers,
martin
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: linux @ 2006-01-09 5:55 UTC (permalink / raw)
To: ltuikov; +Cc: git, linux-kernel
> And lastly, is there a tool whereby I can "see" changes
> between repos, kind of like git-diff but being able to
> give URLs too?
Write it yourself. It's git-fetch + git-diff.
Or, put another way, if you think you need a special tool for working
with a remote repository, you don't understand git-fetch.
Since git history is immutable, there is no difference between a remote
copy and a local copy. And since fetching is harmless to your local
repository, there's no problem.
If you don't want to copy the entire history, just fetch the tree rather
than the commit. (Does git-fetch do that? It's a subset of its current
effects, so would be an easy enough extension.)
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Brown, Len @ 2006-01-09 5:53 UTC (permalink / raw)
To: Martin Langhoff
Cc: David S. Miller, torvalds-3NddpPZAyC0,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
>On 1/9/06, Brown, Len <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> Perhaps the tools should try to support what "a lot of people"
>> expect, rather than making "a lot of people" do extra work
>> because of the tools?
>
>I think it does. All the tricky stuff that David and Junio have been
>discussing is actually done very transparently by
>
> git-rebase <upstream>
>
>Now, git-rebase uses git-format-patch <options> | git-am <options> so
>it sometimes has problems merging. In that case, you can choose to
>either resolve the problem (see the doco for how to signal to git-am
>that you've resolved a conflict) or to cancel the rebase. If you
>choose to cancel the rebase, do
>
> cp .git/refs/heads/{<headname>,<headnamebadrebase>}
> cat .git/HEAD_ORIG > .git/refs/heads/<headname>
> git-reset --hard
> rm -fr .dotest
>
>and you'll be back to where you started. Perhaps this could be rolled
>into something like git-rebase --cancel to make it easier, but that's
>about it. The toolchain definitely supports it.
This is completely insane.
Do you have any idea what "sometimes has problems merging" means
in practice? It means the tools are really nifty in the trivial
case but worse than worthless when you need them the most.
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Martin Langhoff @ 2006-01-09 4:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Adrian Bunk, Brown, Len, David S. Miller,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.64.0601081909250.3169-hNm40g4Ew95AfugRpC6u6w@public.gmane.org>
On 1/9/06, Linus Torvalds <torvalds-3NddpPZAyC0@public.gmane.org> wrote:
> And then do
>
> git-rebase linus
>
> to rebase your development branch to mine.
>
> THIS is what "rebase" is for. It sounds like what you really want to do is
> not have a development branch at all, but you just want to track my tree
> and then keep track of a few branches of your own. In other words, you
> don't really have a "real" branch - you've got an odd collection of
> patches that you really want to carry around on top of _my_ branch. No?
FWIW, I determine whether I should rebase or merge based on
+ Whether the branch/head I maintain is public. For public repos, I
*must* merge carefully as rebase "rewinds" the head and that makes a
mess of any repositor tracking me.
+ Whether the changes on my both sides are significant, and it is
semantically meaningful to have a merge. If either side had just a
couple of minor commits, rebase makes life a lot easier down the path.
If both side clearly saw parallel development, it is more sincere to
merge and let that be recorded.
+ If my attempt to rebase leads to any non-trivial conflicts or
co-dependencies, then I definitely cancel the rebase and merge.
> Now, in this model, you're not really using git as a distributed system.
I'd argue that it is not about distributed or not. It's all in what
you want to record in your history. As such, it is a communication
device -- and I want to make effective use of it. I guess the question
I ask myself is: what will communicate what's happened here most
clearly? What will be useful for people to read? In that context, a
white-lie here and there simplifying the history a bit where it's not
interesting counts as a good thing.
cheers,
martin
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-09 3:50 UTC (permalink / raw)
To: Al Viro
Cc: Brown, Len, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20060109004844.GG27946-rfM+Q5joDG/XmaaqVzeoHQ@public.gmane.org>
On Mon, 9 Jan 2006, Al Viro wrote:
>
> How do you deal with conflict resolution? That's a genuine question -
> I'm not talking about deliberate misuse to hide an attack, just a normal
> situation when you have to resolve something like
>
> A:
> if (foo)
> bar
>
> B:
> if (foo & baz)
> bar
>
> A':
> #ifdef X
> if (foo)
> bar
> ...
> #endif
>
> merge of A' and B: trivial conflict
Actually, these days git is pretty good at it. Much better than CVS,
certainly. You can see the "conflict against my old tree", or "conflict
against the remote tree" by using the "--ours" or "--theirs" flag to "git
diff" respectively.
(Or "diff conflict against common base": "git diff --base").
So for your particular example with a trivial base file:
line 1
2
3
if (foo)
bar
6
7
8
and then the changes you had as an example in the A' and B branches, if I
from A' do a "git pull . B", I get:
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with ad56343c578785b8d932224a8676615e7a3e191f
Merging:
9d619225e3adecee6432a36d67d140e29b0acf62 A' case
ad56343c578785b8d932224a8676615e7a3e191f B: case
found 1 common ancestor(s):
93765ba3f64e9c73438e52683fffa68e5a493df7 Base commit
Auto-merging A
CONFLICT (content): Merge conflict in A
Automatic merge failed; fix up by hand
and then the file contains the contents
line 1
2
3
<<<<<<< HEAD/A
#ifdef X
if (foo)
=======
if (foo && baz)
>>>>>>> ad56343c578785b8d932224a8676615e7a3e191f/A
bar
6
#endif
7
8
ie it will have does a CVS-like merge for me, and I need to fix this up.
However, to _help_ me fix it up, I can now see what the diff is aganst my
original version (A'), with "git diff --ours" (the "--ours" is default, so
it's unnecessary, but just to make it explicit):
* Unmerged path A
diff --git a/A b/A
index 06dd3bc..7334364 100644
--- a/A
+++ b/A
@@ -1,8 +1,12 @@
line 1
2
3
+<<<<<<< HEAD/A
#ifdef X
if (foo)
+=======
+ if (foo && baz)
+>>>>>>> ad56343c578785b8d932224a8676615e7a3e191f/A
bar
6
#endif
which is very helpful especially once I have resolved it. IOW, I just edit
the file and do the trivial resolve, and now I can do a "git diff" again
to make sure that it looks ok:
* Unmerged path A
diff --git a/A b/A
index 06dd3bc..924fc97 100644
--- a/A
+++ b/A
@@ -2,7 +2,7 @@ line 1
2
3
#ifdef X
- if (foo)
+ if (foo && baz)
bar
6
#endif
ahh, looks good, so I just do "git commit A" and that creates the
resolved merge.
> The obvious way (edit file in question, update-index, commit) will not
> only leave zero information about said conflict and actions needed to
> deal with it, but will lead to situation when git whatchanged will not
> show anything useful.
Now, this is a real issue.
The resolve part is pretty easy, but the fact that it's hard to see in
"git-whatchanged" is a limitation of git-whatchanged.
You need to use "gitk", which _does_ know how to show merges as a diff
(and yes, I just checked).
> Is there any SOP I'm missing here?
You're just missing the fact that git-whatchanged (or rather,
"git-diff-tree") isn't smart enough to show merges nicely. It really
_should_. It doesn't. You can choose to show merges with the "-m" flag,
but that will show diffs against each parent, which really isn't what you
want.
I should do the same thing gitk does in git-diff-tree.
> Worse (for my use), format-patch on such tree will not give a useful patchset.
> You get a series of patches that won't apply to _any_ tree.
Now, git-diff-tree _does_ do that. Use the "-m" flag, and choose the tree
you want.
And btw, that works with "git-whatchanged" too. You _can_ pass the "-m"
flag to git-whatchanged, and it will show you each side of the merge
correctly. So it _works_. It's just such a horrible format that by default
it prefers to shut up about merges entirely.
(I don't know of a good three-way diff format. "gitk" can do it, because
gitk can show colors. That's a big deal when you do three-way - or
more-way - diffs).
> And that's a fundamental problem behind all that rebase activity, AFAICS.
You do _not_ want to rebase a merge. It not only won't work, it's against
the whole point of rebasing.
Rebasing is really only a valid operation when you have a few patches OF
YOUR OWN that you want to move up to a new version of somebody elses tree
that you are tracking. You fundamentally _cannot_ rebase if you've done
anything but a linear set of patches. And that has nothing to do with the
patch difficulty - it simply isn't an operation that makes sense.
(Btw, not making sense doesn't mean it might not work. It sometimes might
actually work and do what you _hoped_ it would do, but it's basically by
pure luck, and not because it is a sensible operation. Even stupid
people hit on the right solution every once in a while - not because
they thought about things right, but just because they happened to try
something that worked. The same is true of "git rebase" with merges ;^).
The fundamental reason a rebase doesn't make sense is that if you've done
a merge, it obviously means that some other branch has done development,
and already has the commits that you're trying to rebase. And you CANNOT
rebase for them.
So instead of rebasing across a merge, what you can do is to not do the
merge at all, but instead rebase one of the two branches against the
other. Then you can rebase the result against the thing that you wanted to
rebase them both against. Now you've never rebased a merge - you've just
linearised branches that were linear in themselves against each other.
Basically, a merge ties two branches together. Once you've merged, you
can't make a linear history any more. The merge fundamentally is not
linear.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-09 3:26 UTC (permalink / raw)
To: Adrian Bunk
Cc: Brown, Len, David S. Miller, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20060108230611.GP3774-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org>
On Mon, 9 Jan 2006, Adrian Bunk wrote:
>
> Consider I want to do the following:
> 1. update my tree daily from your tree
> 2. include 10 patches per week into my tree
> 3. ask you once a month to pull from my tree
>
> How should step 1 be done?
I'd do
git fetch linus
to fetch my tree as a branch (obviously, this assumes you've set up a
'.git/remotes/linus' file for the shorthand).
Then, keep your checked-out working-tree that you also do you development
in your 'devel' branch (or whatever).
And then do
git-rebase linus
to rebase your development branch to mine.
THIS is what "rebase" is for. It sounds like what you really want to do is
not have a development branch at all, but you just want to track my tree
and then keep track of a few branches of your own. In other words, you
don't really have a "real" branch - you've got an odd collection of
patches that you really want to carry around on top of _my_ branch. No?
Now, in this model, you're not really using git as a distributed system.
In this model, you're using git to track somebody elses tree, and track a
few patches on top of it, and then "git rebase" is a way to move the base
that you're tracking your patches against forwards..
It's also entirely possible that you may want to look at "stacked git"
(stg), which is really more about a "quilt on top of git" approach. Which
again, may or may not suit your needs better.
Now, the other alternative is to use git as a "real" distributed system,
and then you might keep my "linus" branch around perhaps as a reference
point, but you don't care too much about it. What you care a lot more
about is your "real development" branch, and you simply don't rebase that,
or try to track my branch all that closely. You work in your real
development branch, and that's your bread and butter. You _don't_ merge my
tree every day, because you simply don't care - that's a separate issue.
You might have a totally different directory that you use _just_ to track
my tree, and that is my virgin tree checked out and ready to go to test
what _I_ am doing - totally independently of your tree.
See? Two totally different usage schenarios. In one, you keep a couple of
"odd-ball" patches around (hey, it could be many, but I say a couple just
because the patches aren't a huge deal - they are kind of a small side
project to you, and not the main focus). And you use "git rebase" to move
those patches forward to match the "real" tree, aka mine.
In the other schenario, your development tree is a full-fledged real
branch, with a life of its own, and _not_ slaved to what happens to be
going on in my tree. You may care about my tree for _other_ reasons, but
the two aren't really joined at the hip.
The third schenario is somewhere in between: you do pull from my tree, but
you do it occasionally enough that the merges don't get annoying.
Most people I work with are actually in that gray area. EVERYBODY pulls
some. Nobody tends to do black-and-white either-or schenario. The question
is just how much.
My gut rule: if you have almost as many merges as you have "real work"
commits, you're doing something bad, and you should pull less often
(perhaps by using "rebase", perhaps by just realizing that you don't need
to be tailgating _quite_ that closely).
But 30 "real" commits and 5 merges because the 30 real commits happened
over four weeks time? Sounds fine to me.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] format-patch: Use --mbox by default.
From: Andreas Ericsson @ 2006-01-09 2:05 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43C18EE1.4050807@zytor.com>
H. Peter Anvin wrote:
> Andreas Ericsson wrote:
>
>>
>> The patches generated also had bad mail headers for sendmail (of
>> postfix 2.2.2 at least) to use directly (From: line must be on top,
>> Subject: last of header)
>
>
> Sounds like a bug report against postfix is in order.
>
No need. It works with 2.2.8. The 2.2.2 it failed with is the default
for FC4. I have no interest investigating all the possibilities, and I
doubt Vietse will look for bugs in old versions unless they're security
related.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] format-patch: Use --mbox by default.
From: Andreas Ericsson @ 2006-01-09 2:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd8ezcol.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>This patch enables a slightly modified and more correct --mbox
>>output by default. The --date, --author and --mbox options
>>are obsoleted and removed.
>
>
> I always use format-patch with -k -m (or -k --stdout), so I have
> no objections to making --mbox the default. I do not think
> anybody uses --date or --author in their scripts, but removing
> the --mbox option _might_ break things for people's scripts.
> Maybe it is worthwhile to keep it as a no-op option for a while.
>
The reworked patch (which works for sending patches to myself, so far),
prints a warning to stderr that a deprecated option is used and then
silently ignores it.
>
>>The patches generated also had bad mail headers for sendmail (of
>>postfix 2.2.2 at least) to use directly (From: line must be on top,
>>Subject: last of header),...
>
>
> I do not think RFC2822 specifies that. See "3.6 Field
> definitions", third paragraph, first two sentences.
>
> In that sense, technically they are not "bad mail headers", but
> at the same time, since it is valid in any order, if _one_
> popular MTA is unconfortable with a particular ordering, we
> could order things differently to make it happier (mind you,
> this would not work for more than one such broken MTAs).
>
The only thing I've seen break is if Subject: is placed on top. It's
easier, script-wise, to put it last and that seems to work with qmail
and postfix both.
> Another thing I've been considering is to handle UTF-8 (or
> i18n.commitencoding in general) a bit better. We currently do
> not have Content-Type: header, so if you pipe the output to
> "am", it must be invoked without "-u" to make sure that it takes
> things as-is ("am -u" assumes things are in latin1 without
> Content-Type:). If we start to tackle that issue, we might also
> want to do RFC2047 in headers.
>
>
You'll have to ask someone else for that. I have no idea how it works
and I wouldn't know how to begin doing it in shell.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* What's new in git.git
From: Junio C Hamano @ 2006-01-09 1:20 UTC (permalink / raw)
To: git
Latest maintenance release for GIT 1.0 (1.0.8) and the new
feature release GIT 1.1.0 have been pushed out.
Waiting in the proposed updates branch are two backward
incompatible changes.
- Require packfiles to be named pack-[0-9a-f]{40}.pack, and
issue an warning if [0-9a-f]{40} part does not match the SHA1
checksum of sorted object names that are contained in the
pack. Later I would like to promote the warning to an error,
and there is a tool to help renaming packs created with older
git-pack-objects. When the warning is promoted to an error,
this will break existing packfiles.
- Use textual symbolic refs to represent .git/HEAD everywhere,
not just on filesystems without symbolic link supports. This
was proposed by Pavel mid November 2005, but is known to
break Porcelains that read(2) from .git/HEAD and expect to
read an object name for the current branch head (use "git
rev-parse --verify HEAD" instead), and write(2) into
.git/HEAD and expect to update the current branch head (use
"git update-ref HEAD $commit [$old]" instead). Last time I
checked, gitweb would break with this change.
Also there are patches floating around to update format-patch
and rebase. I rejected the initial round, but consider what
the latter wants to achieve a worthwhile goal, and expect to
update rebase in some form.
Now the core and the barebone Porcelain are more or less stable
and changes have significantly slowed down, I think it is a good
time to start revisiting the libification effort, started by
Smurf. I haven't taken a look at his tree for a while.
Another area that needs attention is to see how we can improve
handling of merges between branches that have renamed things
(i.e. HPA's klibc repositories). I'd also like to teach
renaming merge to resolve strategy somehow.
Other small things I have in mind, in random order, are:
- Give extra option to "diff-tree -m -p" to show difference
between natural merge among parents and the actual merge
result. I do not think this would make sense for non patch
format.
- The recent "git-daemon --base=/pub/git" is a good addition
(git://host/frotz.git is mapped to /pub/git/frotz.git
directory), but with the current implementation whitelist
needs to start with /pub/git/. I initially thought it was
not so nice, but maybe it is OK; but this needs to be
documented. It also forbids user relative paths, which
should be made an independent switch.
- Also in "git-daemon", I outlined --strict-symlink option a
while ago, which forbids symbolic links to step outside of
whitelisted areas. This has not been implemented, and we may
want to add it.
- Although Linus has been pretty negative about improving the
current dumb http transport, many people seem to rely on it.
It "works" with packfiles in the sense that it does not barf,
but the server file packing strategy to reduce duplicated
download needs to be worked out to make it more efficient.
- If the same cloning requests are made number of times, we
should be able to cache the packfile we sent out and reuse,
to reduce the load on the server side. When used with
git-daemon, this requires the daemon to be able to write
somewhere (not necessarily the original repository itself),
so there is certain security implications.
^ permalink raw reply
* [ANNOUNCE] GIT 1.0.8
From: Junio C Hamano @ 2006-01-09 1:20 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.0.8 is available at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.0.8.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.0.8-1.$arch.rpm (RPM)
This is mostly "small fixes" release.
Changes since v1.0.7 are as follows:
Joe English:
Substitute "/" with $opt_s in tag names as well as branch names
Junio C Hamano:
unpack-objects: default to quiet if stderr is not a tty.
Retire debian/ directory.
prune: do not show error from pack-redundant when no packs are found.
Compilation: zero-length array declaration.
tar-tree: finish honoring extractor's umask in git-tar-tree.
revert/cherry-pick: handle single quote in author name.
mailsplit: allow empty input from stdin
GIT 1.0.8
Yann Dirson:
Teach cvsexportcommit to add new files
Fix typo in debug stanza of t2001
Fix git-format-patch usage string wrt output modes.
^ permalink raw reply
* [ANNOUCNE] GIT 1.1.0
From: Junio C Hamano @ 2006-01-09 1:20 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest feature release GIT 1.1.0 is available at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.1.0.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.1.0-1.$arch.rpm (RPM)
This contains all the fixes present in 1.0.8, with the following
enhancements:
- "git clone -o $name" can name a branch other than "origin" to
be used to keep track of upstream (Johannes).
- Easier shared repository setup (Johannes).
- "git describe" command (Linus).
- "git --version" from an interim snapshot gives a more
descriptive version name than "1.0-GIT" (Linus).
- "git whatchanged" shows abbreviated object names by default.
- "git checkout -- paths" and "git checkout treeish paths" use
cwd relative pathname and work from a subdirectory.
- "git checkout [-b newbranch] branch" works from a
subdirectory and works on the entire tree.
- "git ls-tree" shows cwd relative pathnames by default; full
pathnames can be obtained with --full-name, just like "git
ls-files" (Linus and me).
- "git send-pack" and "git push" notice when the remote end
refuses to update a ref (e.g. hooks/update) and exits with an
error. This hopefully would help Cogito as well.
- "git fetch" and "git pull" automatically follows remote tags
while tracking branches.
- "git ls-files --others" can be used with "--directory" option
to omit the contents of directories without any tracked file
but instead to show the directories themselves (Linus). "git
status" uses this to unclutter "Untracked files" section.
- Optimized "git pack-redundant" (Lukas).
- "git daemon --base-path=/pub/git" can reroot the directory
tree exposed to the outside world, similar to DOCUMENT_ROOT
(Pasky).
- "git cherry" can be told not to show everything we have (Yann
Dirson).
- git URL can use [IPv6address/IPvFuture] literal addresses
(Hideaki).
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-09 1:13 UTC (permalink / raw)
To: Luben Tuikov
Cc: Martin Langhoff, Brown, Len, David S. Miller, linux-acpi,
linux-kernel, akpm, git
In-Reply-To: <20060108212057.79825.qmail@web31815.mail.mud.yahoo.com>
On Sun, 8 Jan 2006, Luben Tuikov wrote:
>
> How about this usage (branch == tree):
>
> Tree A (your tree)
> Tree B (project B, dependent on Tree A)
> Tree C (project C, dependent on project B)
>
> (i.e. diff(C-A) = diff(C-B) + diff(B-A))
>
> Your tree is pulled into Tree A as often as your tree
> changes and it just fast forwards.
>
> If I want to run project B with your latest tree, then
> I resolve/merge from tree A to tree B, compile B
> and run it.
>
> If I want to run project C and project B with your
> latest tree, I resolve/merge from tree A to tree B
> and from tree B to tree C, compile C and run it.
No.
If tree B is based on _some_point_in_ A, then you just test that.
Because development line B is _independent_ of development line A. The
fact that A changes doesn't change B - unless they have some real
dependencies (which we should try to avoid).
So when you update ("fetch" in git parlance) branch A from me, that
shouldn't affect branch B _nor_ branch C in any way. They clearly do not
depend on the new stuff in A, since they do their own independent
development. The fact that they _started_ at some random point during the
development of A doesn't change that fact.
Now, if you want to _test_ the combined "new stuff in branch A and new
stuff in branch B", feel free to do that. But realize that that is _not_
appropriate in either branch A _nor_ branch B.
So you'd be much better off with a separate "test" branch that you test
stuff out in, and you then resolve ("pull" in git parlance) both branch A
and branch B into that test branch.
See? Testing the combination of two branches doesn't actually have
anything to do with either branch.
At some point, you decide that you want to merge what you've done in
branch B. That's a _different_ and independent thing from deciding that
you want to test the combination of two development branches. Clearly,
it's great to test often, but that has nothing to do with releasing a
branch.
> In such cases, are you saying that you'd prefer to
> pull from Tree B and Tree C (depending on your needs)?
I'm saying that mixing up the "let's test the combination" and "let's
merge the two branches" are totally different things and should not be
mixed up.
One is a random event (and then it makes sense to have, for example, a
"automated test branch" that automatically merges every day and tests the
results. I don't think you should expose those random merges to others,
because they actually hinder the readability of the history for _both_
sides.
The other is a _directed_ event. It's the event of saying "branch B" is
now ready to be merged. Usually that's best done by just saying "please
pull now" - ie not by merging branch A into branch B (because that's not
what you actually want, is it? What you want is for the development in
branch B to show up in branch A - so you want branch A to do the pull).
Now, there's a third kind of event, which is again independent of the
other two. It's more of a "let's try to keep the 'topic branch'
development up-to-date with the branch we eventually want to merge the
topic changes into". That's where you can now do two things:
- David often "rebases" all of the changes in his "topic branch" (ie
conceptually "branch B") to the new top-of-head of "branch A". In other
words, he re-writes branch B entirely _as_if_ it was based on the newer
state "branch A". This is what "git rebase" is all about.
- You can just pull from branch A into branch B, as a way to keep branch
B more up-to-date with the work in the "main trunk" or whatever. This
is ok, but it shouldn't be a common event. It should be something that
happens when you (for example) notice during testing that the test
merge no longer works cleanly. Or it might be "It's now been two weeks
since I synchronized, let's just synchronize to be safe".
See? I'm not objecting to topic branches pulling from my tree in general.
It's just that they should have a _reason_. There's never any reason to
pull into a development tree that you haven't done any development in,
just because you also want to use that development tree for testing.
> Another question:
> Sometimes, a fix for project B finds its way into
> tree C (project C) (since C depended on that fix in B).
> Now I'd like to pull that particular fix, identified by
> its SHA, into project B, and nothing else, for this I can
> use git-cherry-pick, right?
That's one way. It's often the best way, especially if it's a really
obvious bugfix. Or you could just fix it in your tree yourself. It will
mean that the two branches have the same fix, but especially if it really
is an identical fix, it won't be a merge problem.
You _can_ just decide to pull branch B into branch C, but that has a real
problem, namely that it inexorably links the two together, so that nobody
can then pull branch C without pulling indirectly branch B at the time
that B->C merge happened. Sometimes that is ok. But it's nice to avoid it
if you can.
But for example, if somebody fixed something in the trunk, and you
actually do need that fix from the trunk for your topic branch
development, then just doing a pull is _fine_. Now we're back to doing a
merge that actually has a perfectly good reason.
IOW, don't cherry-pick to avoid merges when the merge really does make
tons of sense. Merges are good, it's just that _too_ much of a good thing
is bad.
> And lastly, is there a tool whereby I can "see" changes
> between repos, kind of like git-diff but being able to
> give URLs too?
No, all the good tools really are based on fetching (NOT "pulling") the
other branch into your local tree as a separate branch. At that point,
there are tons of wonderful tools you can use.
In other words, say that you want to know what has happened in another
repository, at git://git.kernel.org/xyzzy. You aren't interested in the
stuff that is already part of the trunk, you're just interested in what is
only in that "xyzzy" branch, and how it relates to your code.
What you'd do is
git fetch git://git.kernel.org/xyzzy master:xyzzy-snapshot
which says "fetch the 'master' branch from that xyzzy repository, and call
it 'xyzzy-snapshot' locally.
You can then (for example) fetch the code that is in _my_ tree by doign
the same time (just call that branch 'linus'), and you can now do
gitk linus..xyzzy-snapshot HEAD
which looks strange (you give "gitk" _both_ a range from the "linus"
branch to the "xyzzy-snapshot" _and_ your own HEAD at this time), but what
it basically does is that the "linus.." syntax tells git that you're not
interested in anything that is already in the 'linus' branch.
So the above command line will actually graphically show _both_ your
current HEAD branch _and_ the 'xyzzy-snapshot' branch, in parallel. You
can see how (if at all) they are related to each other, ignoring all the
commits that have already made it into my tree.
(You can also do "linus..HEAD" instead of just HEAD and effectively repeat
the "don't show 'linus' branch any more" twice. It's perfectly equivalent,
of course. You may also want to use the "-d" flag to "gitk" which tells it
to show things in date order, instead of a simplified history order).
Or just do "what has xyzzy-snapshot that I do not have in my HEAD":
git log HEAD..xyzzy-snapshot
(or gitk), or the other way around: what do _I_ have in my HEAD that
hasn't been pushed to xyzzy-snapshot yet:
git log xyzzy-snapshot..HEAD
(or do diffs, "git whatchanged -p", or whatever).
In other words, using a few different branches (you can make them up
dynamically) can be very powerful.
Linus
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Al Viro @ 2006-01-09 0:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brown, Len, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <Pine.LNX.4.64.0601081100220.3169@g5.osdl.org>
On Sun, Jan 08, 2006 at 11:10:20AM -0800, Linus Torvalds wrote:
> That has absolutely nothing to do with anything. It's not the comment
> (which admittedly gives absolutely no information - but why should it,
> since the _commit_ itself has no information in it?)
How do you deal with conflict resolution? That's a genuine question -
I'm not talking about deliberate misuse to hide an attack, just a normal
situation when you have to resolve something like
A:
if (foo)
bar
B:
if (foo & baz)
bar
A':
#ifdef X
if (foo)
bar
...
#endif
merge of A' and B: trivial conflict
and have git pull fail. The obvious way (edit file in question, update-index,
commit) will not only leave zero information about said conflict and actions
needed to deal with it, but will lead to situation when git whatchanged will
not show anything useful. I.e. if conflict turns out to be non-trivial and
ends up being resolved wrong, everyone will have very nasty time trying to
figure out where the breakage had come from when looking at history 6 months
down the road.
Is there any SOP I'm missing here?
Worse (for my use), format-patch on such tree will not give a useful patchset.
You get a series of patches that won't apply to _any_ tree. Even if all
conflicts had been resolved correctly, they still remain there for everyone
trying to apply the patch series, unless you manually rebase it before
format-patch.
And that's a fundamental problem behind all that rebase activity, AFAICS.
It definitely is in my case, and yes, it's fscking inconvenient in a lot
of respects. E.g. I'm using git for resync between build trees on several
boxen. There's a repository holding patchset, plus one clone per build
box. Fixes for build breakage, etc., get done in those clones; after they
are committed there, I pull into master and then pull from other clones
to spread them to other build trees. Works fine, but... Any rebase in
master => instant hell for all clones. I've ended up with the following
layout that kinda-sorta avoids mess:
master:origin: matches upstream
master:topic branch: _not_ rebased until there is a conflict, never get
a pull from anywhere
master:master: gets pulls from topic branches and origin _and_ _nothing_ _else_
master:work: where interaction with build boxen and any edits done in master
repository go. Edits, commits, pulls from master:master, pulls from
build boxen.
buildN:origin == master:work
buildN:work: where work on buildN goes.
When I want to get new stuff (== difference between master:master and
master:work) into the patchset, I cherry-pick from work to topic branches
and re-pull them into master:master until it matches master:work. Then
I pull master:master into master:work to create a point in work history
that marks beginning of new portion of pending stuff. New stuff upstream
is pulled to master:origin -> master:master -> master:work -> build trees.
That works, and gives me merge-free topic branches I can safely format-patch
while keeping master in sync with mainline _and_ also safe for format-patch.
The price is in rather convoluted SOP. And the following piece of fun:
when cherry-pick work->topic, pull topic->master or pull origin->master
gives a conflict, it's time to rebase. Which I do by renaming topic branches
(direct mv in .git/refs/heads), then starting new ones at current origin
and applying old ones to them (cherry + cherry-pick if possible, format-patch
+ applymbox if things get hairy). Then master is recreated as branch from
origin that gets pulls from topic branches, work is branched from it and
build trees get killed and cloned from scratch. It's tolerable since I'm
using ccache on build boxen, so it's _not_ that much of rebuild.
However, that clearly is a killer if any poor sucker (me included) ever
clones from master for any other purpose. And that, BTW, is the main
reason that stops me from moving master to kernel.org right now.
> And yes, you can always work around it, but there's just no point. And
> none of the other developers seem to need to do it. They do their
> development, and then they say "please pull". At that point the two
> histories are tied together, but now they are tied together for a
> _reason_. It was an intentional synchronization point.
>
> An "automated pull" by definition has no reason. If it works automated,
> then the merge has zero semantic meaning.
I'm afraid you are missing a part of picture. There is a bunch of git
uses that handle a heap of foam rather than a long-term branching. I.e.
the tree is tied to mainline closely and most of the stuff in it is
supposed to get flushed into mainline soon after it appears. I.e. the
situation when we have a mergepoint for fixes that _has_ to follow
mainline closely.
I wonder what life would be without merge nodes and with equality nodes
instead. I.e. to merge
O -> A1 -> ..... -> An (=A)
-> B1 -> ..... -> Bm (=B)
would be to create a new branch (C) at Bm, have entire A1...An replayed there,
have B1...Bm replayed in A and then create a node certifying that new head
of A and head of C refer to the same tree. Plus have a way to see which
commits are claimed to be replays of each other. At least that way rebase
would be simply saying that old history is superceded by new one, with
equality node proving that it's OK to do. We would have
O -> M1 -> .... ->Mn for mainline
O -> B1 -> .... -> B for branch post-pull
Mn -> P1 -> ... -> P for merge branch
and B == P as equality node. Old branch would have a bunch of changesets
of its own plus ones from mainline that got there by pulls (including the
last one). And new branch would contain the ports of not-yet-merged ones
to new mainline head, with the same tree as the result and all further
development going on there rather than in the old branch. Oh, well...
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Willy Tarreau @ 2006-01-08 23:53 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Brown, Len, David S. Miller,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20060108230611.GP3774-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org>
Hi Adrian,
On Mon, Jan 09, 2006 at 12:06:11AM +0100, Adrian Bunk wrote:
> On Sun, Jan 08, 2006 at 11:41:28AM -0800, Linus Torvalds wrote:
> >...
> > What I object to is that there were _also_ two automated merges within ten
> > hours or each other, with absolutely _zero_ development in your tree in
> > between. Why did you do that in your development tree? By _definition_ you
> > had done zero development. You just tracked the development in _my_ tree.
> >...
>
> My impression is that you and Len are talking at different levels.
>
> I can't speak for Len, but let me try to describe a problem in this area
> I don't know the solution for:
>
> Consider I want to do the following:
> 1. update my tree daily from your tree
> 2. include 10 patches per week into my tree
> 3. ask you once a month to pull from my tree
>
> How should step 1 be done?
I believe we all have the same problem. The only solution I found for
this was to proceed like David described. I know even have a 'git-patches'
directory next to my git repo to keep the resulting patches after I do a
'git-format-patch --mbox'.
When Linus called it the 'stupid content tracker', he was half right.
In fact, it's more a 'changes tracker' than a 'content tracker'. It
logs everything you and others do, so if you don't want your operations
to appear on others' history, you have to hide them by working on
temporary trees to generate the patches you will use later.
At first I found this very annoying, but finally, it's a way to ensure
that I always have clean and ordered patches. It's not much different
from what I was doing by hand previously, it's just that all git-xxx
operations take much longer time, possibly because of the compression.
On the other hand, its ability to understand mbox saves me some time.
> In CVS, I'd do a "cvs update -dP ."
> In cogito, the equivalent command seems to be "cg-update".
>
> CVS has no problems if I have changed MAINTAINERS in one place and it
> changes daily in your tree in other places, but how do I do the same in
> git/cogito without creating the merges you don't want to see?
>
> The solution might be described somewhere in TFM, but this is the class
> of problems people like me run into when the goal is simply a git tree
> to both track your tree and send changes to you without any interest in
> advanced SCM knowledge.
What sometimes worries me is that some operations seem so much complicated
that there is a high risk of doing the wrong thing, and I'm not certain
that this will reduce the number of mistakes I do in a month, compared
to manual patching. I became a real addict to 'git-reset --hard' ...
> cu
> Adrian
Regards,
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git-format-patch Date header
From: Andreas Ericsson @ 2006-01-08 23:30 UTC (permalink / raw)
To: git
In-Reply-To: <43C18CC7.3050509@zytor.com>
H. Peter Anvin wrote:
> Andreas Ericsson wrote:
>
>>
>> Nopes. In this case fixing my home-hacked git-send-patch script is the
>> right thing to do. git-format-patch has always printed that format,
>> though, so the error lies with me and the patch I sent. I shall have
>> to re-visit it after reading rfc 822 a bit more closely.
>>
>
> RFC 2822, please.
>
Right you are.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Adrian Bunk @ 2006-01-08 23:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Brown, Len, David S. Miller, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <Pine.LNX.4.64.0601081111190.3169-hNm40g4Ew95AfugRpC6u6w@public.gmane.org>
On Sun, Jan 08, 2006 at 11:41:28AM -0800, Linus Torvalds wrote:
>...
> What I object to is that there were _also_ two automated merges within ten
> hours or each other, with absolutely _zero_ development in your tree in
> between. Why did you do that in your development tree? By _definition_ you
> had done zero development. You just tracked the development in _my_ tree.
>...
My impression is that you and Len are talking at different levels.
I can't speak for Len, but let me try to describe a problem in this area
I don't know the solution for:
Consider I want to do the following:
1. update my tree daily from your tree
2. include 10 patches per week into my tree
3. ask you once a month to pull from my tree
How should step 1 be done?
In CVS, I'd do a "cvs update -dP ."
In cogito, the equivalent command seems to be "cg-update".
CVS has no problems if I have changed MAINTAINERS in one place and it
changes daily in your tree in other places, but how do I do the same in
git/cogito without creating the merges you don't want to see?
The solution might be described somewhere in TFM, but this is the class
of problems people like me run into when the goal is simply a git tree
to both track your tree and send changes to you without any interest in
advanced SCM knowledge.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] format-patch: Use --mbox by default.
From: H. Peter Anvin @ 2006-01-08 22:14 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <20060108140109.909925BE8D@nox.op5.se>
Andreas Ericsson wrote:
>
> The patches generated also had bad mail headers for sendmail (of
> postfix 2.2.2 at least) to use directly (From: line must be on top,
> Subject: last of header)
Sounds like a bug report against postfix is in order.
-hpa
^ permalink raw reply
* Re: git-format-patch Date header
From: H. Peter Anvin @ 2006-01-08 22:05 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Timo Hirvonen, git
In-Reply-To: <43C13369.4090809@op5.se>
Andreas Ericsson wrote:
>
> Nopes. In this case fixing my home-hacked git-send-patch script is the
> right thing to do. git-format-patch has always printed that format,
> though, so the error lies with me and the patch I sent. I shall have to
> re-visit it after reading rfc 822 a bit more closely.
>
RFC 2822, please.
-hpa
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Luben Tuikov @ 2006-01-08 21:20 UTC (permalink / raw)
To: Linus Torvalds, Martin Langhoff
Cc: Brown, Len, David S. Miller, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <Pine.LNX.4.64.0601081141450.3169@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> So trying out git-rebase and git-cherry-pick just in case you decide to
> want to use them might be worthwhile. Making it part of your daily routine
> like David has done? Somewhat questionable, but hey, it seems to be
> working for David, and it does make some things much easier, so..
How about this usage (branch == tree):
Tree A (your tree)
Tree B (project B, dependent on Tree A)
Tree C (project C, dependent on project B)
(i.e. diff(C-A) = diff(C-B) + diff(B-A))
Your tree is pulled into Tree A as often as your tree
changes and it just fast forwards.
If I want to run project B with your latest tree, then
I resolve/merge from tree A to tree B, compile B
and run it.
If I want to run project C and project B with your
latest tree, I resolve/merge from tree A to tree B
and from tree B to tree C, compile C and run it.
In such cases, are you saying that you'd prefer to
pull from Tree B and Tree C (depending on your needs)?
Another question:
Sometimes, a fix for project B finds its way into
tree C (project C) (since C depended on that fix in B).
Now I'd like to pull that particular fix, identified by
its SHA, into project B, and nothing else, for this I can
use git-cherry-pick, right?
And lastly, is there a tool whereby I can "see" changes
between repos, kind of like git-diff but being able to
give URLs too?
Luben
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Tony Luck @ 2006-01-08 20:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Martin Langhoff, Brown, Len, David S. Miller,
linux-acpi, linux-kernel, akpm, git
In-Reply-To: <Pine.LNX.4.64.0601081156430.3169@g5.osdl.org>
I'll try to update the using-topic-branches document to capture this.
Some of the problem is that it doesn't quite capture what I'm doing
with my test/release branches.
My release branch really is just used as a transfer point to Linus.
I usually[1] don't leave patches sitting in "release" for long enough
that I'll be tempted to merge in from Linus ... once I decide that
some patches are ready to go to Linus I'll update "release" from Linus
(which will be a fast-forward, so no history) merge in the topic
branches, do one final sanity build, push to kernel.org and send
the "please pull" e-mail.
The huge majority of my "automatic update from upstream" merges
go into my test branch ... which never becomes part of the real
history as I never ask Linus to pull from it.
-Tony
[1] Sometimes I goof on this because I forget that I've applied
a trivial patch directly to the release branch without going through
a topic branch. I think I'll fix my update script to check for this case.
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: David S. Miller @ 2006-01-08 20:35 UTC (permalink / raw)
To: torvalds; +Cc: martin.langhoff, len.brown, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <Pine.LNX.4.64.0601081141450.3169@g5.osdl.org>
From: Linus Torvalds <torvalds@osdl.org>
Date: Sun, 8 Jan 2006 11:56:21 -0800 (PST)
> So my suggested git usage is to _not_ play games. Neither do too-frequent
> merges _nor_ play games with git-rebase.
>
> That said, git-rebase (and associated tools like "git-cherry-pick" etc)
> can be a very powerful tool, especially if you've screwed something up,
> and want to clean things up. Re-doing history because you realized that a
> you did something stupid that you don't want to admit to anybody else.
>
> So trying out git-rebase and git-cherry-pick just in case you decide to
> want to use them might be worthwhile. Making it part of your daily routine
> like David has done? Somewhat questionable, but hey, it seems to be
> working for David, and it does make some things much easier, so..
The time at which I do the by-hand rebasing the most are the weeks
leading up to a major release. The reason is to integrate bug fixes
that I know conflict with the 80-odd patches I have queued up for the
next development phase, or that I simply want integrated so that no
_future_ development patches create conflicts.
I think merges with conflicts that need to get resolved by hand create
a lot of noise and useless information and therefore to me they are
pointless. But this is just my opinion. It simply works easier to me
to shuffle the patches in by hand and deal with the rejects one by
one. It's very much akin to how Andrew's -mm tree works.
I think a clean history is worth an extra few minutes of someone's
time. And note that subsystem development is largely linear anyways.
^ permalink raw reply
* Re: [PATCH] format-patch: Use --mbox by default.
From: Junio C Hamano @ 2006-01-08 20:28 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20060108140109.909925BE8D@nox.op5.se>
Andreas Ericsson <ae@op5.se> writes:
> This patch enables a slightly modified and more correct --mbox
> output by default. The --date, --author and --mbox options
> are obsoleted and removed.
I always use format-patch with -k -m (or -k --stdout), so I have
no objections to making --mbox the default. I do not think
anybody uses --date or --author in their scripts, but removing
the --mbox option _might_ break things for people's scripts.
Maybe it is worthwhile to keep it as a no-op option for a while.
> Previously, author-info and date was by default only printed if the
> commit was made by someone else, irrespective of the obsoleted options.
> Since it does no harm having ones own info there too it shouldn't really
> matter much, and should lessen the confusion regarding how to use
> git-format-patch with git-am.
True. Originally it was really "format my changes to
submission" tool (--signoff option is a sure sign to tell you
that) and propagating authorship info was added as afterthought.
> The patches generated also had bad mail headers for sendmail (of
> postfix 2.2.2 at least) to use directly (From: line must be on top,
> Subject: last of header),...
I do not think RFC2822 specifies that. See "3.6 Field
definitions", third paragraph, first two sentences.
In that sense, technically they are not "bad mail headers", but
at the same time, since it is valid in any order, if _one_
popular MTA is unconfortable with a particular ordering, we
could order things differently to make it happier (mind you,
this would not work for more than one such broken MTAs).
Another thing I've been considering is to handle UTF-8 (or
i18n.commitencoding in general) a bit better. We currently do
not have Content-Type: header, so if you pipe the output to
"am", it must be invoked without "-u" to make sure that it takes
things as-is ("am -u" assumes things are in latin1 without
Content-Type:). If we start to tackle that issue, we might also
want to do RFC2047 in headers.
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-08 19:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Langhoff, Brown, Len, David S. Miller, linux-acpi,
linux-kernel, akpm, git
In-Reply-To: <7vace61plu.fsf@assigned-by-dhcp.cox.net>
On Sun, 8 Jan 2006, Junio C Hamano wrote:
>
> Careful. I do not think rebase works across merges at all.
Right. You have to do one or the other (rebase your changes to another
tree _or_ merge another tree into your changes), but not mix the two.
Linus
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-08 19:56 UTC (permalink / raw)
To: Martin Langhoff
Cc: Brown, Len, David S. Miller, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <46a038f90601081119r39014fbi995cc8b6e95774da@mail.gmail.com>
On Mon, 9 Jan 2006, Martin Langhoff wrote:
>
> I think it does. All the tricky stuff that David and Junio have been
> discussing is actually done very transparently by
>
> git-rebase <upstream>
Yes, it's fairly easy to do. That said, I would actually discourage it. I
haven't said anything to David, because he is obviously very comfy with
the git usage, and it _does_ result in cleaner trees, so especially since
the networking code ends up being the source of a lot of changes, the
extra cleanup stage that David does might actually be worth it for that
case.
But git is actually designed to have parallel development, and what David
does is to basically artificially linearize it. We merge between us often
enough that it doesn't really end up losing any historical information
(since David can't linearize the stuff that we already merged), but in
_theory_ what David does actually does remove the historical context.
So "git-rebase" is a tool that is designed to allow maintainers to (as the
command says) rebase their own development and re-linearize it, so that
they don't see the real history. It's basically the reverse of what Len is
doing - Len mixes up his history with other peoples history in order to
keep them in sync, while David bassically "re-does" his history to be on
top of mine (to keep it _separate_).
The "git-rebase" means that David will always see the development he has
done/merged as being "on top" of whatever my most recent tree is. It's
actually a bit scary, because if something goes wrong when David re-bases
things, he'll have to clean things up by hand, and git won't help him
much, but hey, it works for him because (a) things seldom go wrong and (b)
he appears so comfortable with the tool that he _can_ fix things up when
they do go wrong.
And yes, git-rebase can be very convenient. It has some problems too
(which is the other reason I don't try to convince other maintainers to
use it): because it re-writes history, a change that _might_ have worked
in its original place in history might no longer work after a rebase if it
depended on something subtle that used to be true but no longer is in the
new place that it has been rebased to.
Which just means that a commit that was tested and found to be working
might suddenly not work any more, which can be very surprising ("But I
didn't change anything!").
On the other hand, this is no different from doing a merge of two
independent streams of development, and getting a new bug that didn't
exist in either of the two, just because they changed the assumptions of
each other (ie not a _mismerge_, but simply two developers changing
something that the other depended on it, and the bug only appears when
both the working trees are merged and the end result no longer works).
So my suggested git usage is to _not_ play games. Neither do too-frequent
merges _nor_ play games with git-rebase.
That said, git-rebase (and associated tools like "git-cherry-pick" etc)
can be a very powerful tool, especially if you've screwed something up,
and want to clean things up. Re-doing history because you realized that a
you did something stupid that you don't want to admit to anybody else.
So trying out git-rebase and git-cherry-pick just in case you decide to
want to use them might be worthwhile. Making it part of your daily routine
like David has done? Somewhat questionable, but hey, it seems to be
working for David, and it does make some things much easier, so..
Linus
^ permalink raw reply
* RE: git pull on Linux/ACPI release tree
From: Linus Torvalds @ 2006-01-08 19:41 UTC (permalink / raw)
To: Brown, Len; +Cc: David S. Miller, linux-acpi, linux-kernel, akpm, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B3005A13505@hdsmsx401.amr.corp.intel.com>
On Sun, 8 Jan 2006, Brown, Len wrote:
>
> Perhaps the tools should try to support what "a lot of people"
> expect, rather than making "a lot of people" do extra work
> because of the tools?
>
> Call me old fashioned, but I believe that tools are supposed to
> make work easier, not harder.
They DO.
Len, you're doing EXTRA WORK that is pointless.
Just stop doing the automated merges. Problems solved. It really is that
easy. Don't do what David suggests - he does it because he's apparently
_so_ comfortable with things that he prefers to do extra work just to keep
his trees extra clean (I actually would disagree - but git makes that
fairly easy to do, so if you prefer to have as linear a history as
possible, you can do it with git pretty easily).
Now, I'm only complaining about _automated_ merges. If you have a reason
to worry about my tree having clashes with your tree, do a real merge. For
example, in your latest pull, you had a
"pull linus into release branch"
merge, where you merged my v2.6.15 tree. That makes perfect sense.
What I object to is that there were _also_ two automated merges within ten
hours or each other, with absolutely _zero_ development in your tree in
between. Why did you do that in your development tree? By _definition_ you
had done zero development. You just tracked the development in _my_ tree.
In case you wonder, the two commits I'm talking about are:
add5b5ee992e40c9cd8697ea94c223628be162a7
25da0974601fc8096461f3d3f7ca3aab8e79adfb
and neither of them have any reason to be in a development tree. You
didn't develop them.
They are real merges, because you had a trivial patch in your tree
(changing the acpi-devel mailing list address) that I didn't have, so when
you pulled, your end result was thus always different from something I had
(so you did a real "merge", even though it was totally trivial), but the
point is that there is a difference between "the ACPI development tree"
and "the tree that has random ACPI patches and then tracks Linus' tree as
closely as possible".
See?
That's the most egregious example. There's two unnecessary pulls on
December 28 and 29th too (commits 0a5296dc and c1a959d8).
You can do
gitk 0aec63e..f9a204e1
to see exactly what I see when I pulled from you. 11 commits, 5 of which
are just trivial merges that are no development, just tracking _my_ tree.
Of those, one makes sense (tracking a release).
(NOTE NOTE NOTE! It does make sense to track my tree in case you do big
changes and you worry about clashes. Then you would want to synchronize
those big changes with my changes, so that you can resolve any clashes
early. So I'm not saying that tracking trees is always bad: I'm saying
that doing so _unnecessarily_ is bad, because it adds no value, and it
just makes the history harder to read).
Now, most people don't read the history. It gets messy enough quickly
enough that it's hard to read anyway over time. My tree has tons of _real_
merges anyway, since it's by definition the one that is used for most
synchronization, so my tree is always pretty hard to follow.
But my guess is that this probably makes it harder for _you_ to see what
you've done too. If you didn't merge with me, then "git log" would show
just your own changes at the top, and that's likely what you care most
about anyway, no?
Also, if you didn't pull from me, and you decided that you needed to re-do
your tree (let's say that you notice that one of your commits was bad
_before_ you ask me to pull from your tree), then you'd also have an
easier time re-creating your own development without that buggy change,
exactly because _your_ tree wouldn't have my changed mixed up in it.
So your merges likely make git harder to use for you, not easier.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox