* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Carl Worth @ 2006-11-17 16:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611170836120.3349@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
On Fri, 17 Nov 2006 08:45:39 -0800 (PST), Linus Torvalds wrote:
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> >
> > gitk HEAD@{1}..
>
> Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is
> AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's
> "three pretty complicated characters longer" and "off the normal path
> where you hold your fingers on the keyboard ;)
It's not even all that convenient on a U.S. keyboard. My pinky suffers
a bit having to pop on and off of shift for the '{', '1', '}'. Then
again, I don't like having to hold shift down for all of ORIG_HEAD
either, (but it's definitely easier in comparison).
But since reflog does everything ORIG_HEAD does and more, shall we
just clean up the syntax somehow? Ideas anyone? And then fix the
documentation to explain that?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Petr Baudis @ 2006-11-17 16:53 UTC (permalink / raw)
To: Sean; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20061117113404.810fd4ea.seanlkml@sympatico.ca>
On Fri, Nov 17, 2006 at 05:34:04PM CET, Sean wrote:
> It's just that the separate Cogito tool shouldn't have a place on the
> Git website any more prominent than say StGit does.
It doesn't - look at the "Maintaining external patches" crash course.
Porcelains are integral part of the Git environment. I think several
people have already tried to explain it before.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-17 16:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Worth, Junio C Hamano, Michael K. Edwards, git
In-Reply-To: <Pine.LNX.4.63.0611171103150.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I introduced the remote.<nick>.{url,fetch,push} entries into the config
> with the goal to enhance -fetch to remember the current command line with
> a setting. I was the only one to find that useful.
>
> BTW I still would argue that it is better to write the remote information
> into the config, because you have a saner way to manipulate that from
> scripts than .git/remotes/<nick>.
I'm *fully* in favor of the remote.<nick>.{url,fetch,push} entries
in the config file. I've pretty much switched every repository to
that format at this point.
In writing git-gui I'm finding it much, much easier to manage
things through repo-config than to do any mucking around in the
.git/remotes directory. Yes, the remote files have simple format,
but I can get everything in one "git repo-config --list" pull it
all into a Tcl array and work with it; using .git/remotes means I
have to open the file and read each line too. :-(
--
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Sean @ 2006-11-17 17:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20061117165333.GR4842@pasky.or.cz>
On Fri, 17 Nov 2006 17:53:33 +0100
Petr Baudis <pasky@suse.cz> wrote:
> On Fri, Nov 17, 2006 at 05:34:04PM CET, Sean wrote:
> > It's just that the separate Cogito tool shouldn't have a place on the
> > Git website any more prominent than say StGit does.
>
> It doesn't - look at the "Maintaining external patches" crash course.
>
> Porcelains are integral part of the Git environment. I think several
> people have already tried to explain it before.
>
There is enough native Git documentation and hopefully more coming
that third party tools should be pushed behind the scenes a bit.
At least on the GIT website.
Of course there is nothing wrong with having information there, but
the main thrust should be about Git and how to use it directly without
porcelains. Especially in the light that people have recently
expressed a desire to advocate and document the use of native Git
more strongly.
Having a link to Cogito off the front page of the Git website that
says... Cogito makes things "easier", no matter how much you
personally believe it, isn't the way everyone feels and is at
odds with the native-git message and improvement effort.
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Shawn Pearce @ 2006-11-17 17:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611170836120.3349@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> On Fri, 17 Nov 2006, Shawn Pearce wrote:
> >
> > Although if you have reflog enabled on your current branch there
> > is a 1 character shorter syntax:
> >
> > gitk HEAD@{1}..
>
> Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is
> AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's
> "three pretty complicated characters longer" and "off the normal path
> where you hold your fingers on the keyboard ;)
I forgot that you use a finnish keyboard. :-)
I agree with you; its not easier to type, for you. Me, I'm a dumb
American who uses a Kinesis keyboard, therefore my left foot is
my shift key and its in sync with my fingers. I have no extra
pinky load for either syntax. And since the reflog syntax works
in a lot more contexts (e.g. after a fetch into a tracking branch)
I have just forgotten about ORIG_HEAD entirely. Oh sure, I know
its there, but its not something I think about using...
--
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Shawn Pearce @ 2006-11-17 17:15 UTC (permalink / raw)
To: Carl Worth; +Cc: Linus Torvalds, Han-Wen Nienhuys, Junio C Hamano, git
In-Reply-To: <87bqn6qav2.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> Yes, this was my exact thought when reading what Linus
> wrote. ORIG_HEAD might be fine and all, but it pales in functionality
> compared to what reflog provides.
>
> I would very much like to see reflog getting first-class citizen
> support in git:
>
> 1. Be on by default
I have:
git repo-config --global core.logAllRefUpdates true
especially since Junio fixed it to only create logs for heads and
not tags. That way its on by default for me. But I think it should
be on by default in the next version of Git.
> 2. Get documented in all the right places, (much better than adding
> documentation for ORIG_HEAD in my opinion)
Agreed. I'm not likely to do it anytime soon however, so I'm hoping
someone else will do it... :-)
> 3. Tighter integration with branch manipulations. Do we already delete
> reflog when deleting a branch? We don't have a branch rename
> operation, but if we get one, renaming the reflog should go
> hand-in-hand, etc.
Yes, we delete the log when we delete the branch, and we prune
back the empty directories too just like we do on the branch side,
so that new branches can be correctly created.
There was a recent discussion about that from Junio if I recall.
Several people that I work with have asked that branch rename
support be added to Git, and that if you rename the branch the
reflog follows. Because in their mind they are simply changing
the name of the branch, any old history of that branch should
stick around.
I tried to think of an option to "git branch" to do the rename but
kept thinking that:
git rename-branch old new
is the better syntax... even though that's command number 133
or something like that...
We should stick a "null" event into the reflog during a branch
rename. Make both the old and new SHA1 the current SHA1 but drop
a message in saying "renamed branch old -> new" (for example).
--
^ permalink raw reply
* Re: multi-project repos
From: Junio C Hamano @ 2006-11-17 17:39 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Han-Wen Nienhuys, git
In-Reply-To: <20061117162605.GA32597@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Linus Torvalds <torvalds@osdl.org> wrote:
>> - "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
>> (or some other operations, like "git rebase" and "git reset": think of
>> it as a "original head before we did some uncontrolled operation
>> where we otherwise can't use HEAD^ or similar")
>>
>> I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see
>> when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a
>> pull I've done. This is important exactly because ORIG_HEAD is _not_
>> the same as the first parent of a merge, since a merge could have been
>> just a fast-forward.
>
> Although if you have reflog enabled on your current branch there
> is a 1 character shorter syntax:
>
> gitk HEAD@{1}..
Are you sure about this? I've seen "next@{1}" to look at
history of the named branch, but never history of "HEAD".
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-17 17:41 UTC (permalink / raw)
To: Alexandre Julliard, Junio C Hamano; +Cc: git
In-Reply-To: <87y7qahvbp.fsf@wine.dyndns.org>
Alexandre Julliard wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Alexandre Julliard wrote:
>>> Junio C Hamano <junkio@cox.net> writes:
>>>
>>>> I would rather say "use 'git branch' to make sure if you are
>>>> ready to merge". Who teaches not to use "git pull"?
>>>
>>> We do that for Wine. The problem is that we recommend using git-rebase
>>> to make it easier for occasional developers to keep a clean history,
>>> and rebase and pull interfere badly.
>>
>> What about proposed (and I think not accepted) merge strategy
>> "rebase" (formerly called "subordinate" or something like that)?
>
> That sounds very interesting. Has it ever been implemented, or only
> discussed?
There was some implementation with warts
http://thread.gmane.org/gmane.comp.version-control.git/30068
Message-Id: <20061025155009.GD5591@parisc-linux.org>
which didn't got corrected and resent.
--
Jakub Narebski
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: J. Bruce Fields @ 2006-11-17 17:44 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061116221701.4499.qmail@science.horizon.com>
This has some useful material that fills gaps in the existing
documentation. We need to think a little more about the intended
audience, and about how to fit it in with existing documentation.
On Thu, Nov 16, 2006 at 05:17:01PM -0500, linux@horizon.com wrote:
> * A brief digression on command names.
>
> Originally, all git commands were named "git-foo". When there got to
> be over a hundred, people started complaining about the clutter in
> /usr/bin. After some discussion, the following solution was reached:
>
> - It's now possible to place all of the git-foo commands into a separate
> directory. (Despite the complaints, not too many people are doing it
> yet.)
> - One option for git users is to add that directory to their $PATH.
> - Another is provided by a wrapper called just "git". It's intended to
> live in a public directory like /usr/bin, and knows the location of
> the separate directory. When you type "git foo", it finds and executes
> "git-foo".
> - Some simple commands are built into the git wrapper. When you type
> "git add", it just does it internally. (On the git mailing list,
> you will see patches like "make git diff a builtin"; this is what
> they're talking about.)
> - For compatibility, for each builtin, there is a "git-add" file,
> which is just a link to the "git" wrapper. It looks at the name it
> was invoked as to figure out what it should do.
>
> The one confusing thing is that, although people usually type "git foo"
> in examples, they're interchangeable in practice. I go back and forth
> for no good reason. The main caveat is that to get the man page, you
> still need to type "man git-foo". Fortunately, there are two other ways
> to get the man page:
>
> 1) "git help foo"
> 2) "git foo --help"
>
> Git doesn't have a specialized built-in help system; it just shows you
> the man pages.
Who's the audience for the above? I can see that it's useful for
administrators, who may need help deciding how to install stuff, and for
developers, who need to know where the heck the code for "git-add" came
from. But the case I'm most interested in is the user whose
distribution installs git for them, in which case I think the above
could be distilled down to:
- "git-foo" and "git foo" can be used interchangeably.
- Documentation for the command foo is available from any of
- man git-foo
- git help foo
- git foo --help
Then the additional details above could be postponed to a later part of
the documentation.
> One outstanding problem with git's man pages is that often the most detail
> is in the command page that was written first, not the user-friendly
> one that you should use. For example, there are a number of special
> cases of the "git diff" command that were written first, and the man
> pages for these commands (git-diff-index, git-diff-files, git-diff-tree,
> and git-diff-stages) are considerably more informative than the page for
> plain git-diff, even though that's the command that you should use 99%
> of the time.
I agree that that's helpful. Though we should probably also be working
on the man pages to make this organization clearer.
> As you recall from Git 101
Obviously a more specific reference would be more useful here--if
there's nothing useful to point to among the existing documentation, we
should figure out how to fix that problem.
That might also remove the need for some of the recap that follows.
> there are exactly four kinds of objects in
> Git's object database. All of them have globally unique 40-character hex
....
> Finally, there are references, stored in the .git/refs directory.
> These are the human-readable names associated with commits, and the
> "root set" from which all other commits should be reachable.
This is good; a comprehensive discussion of references will fill a gap
in the current documentation.
....
> * Naming revisions
>
> CVS encourages you to tag like crazy, because the only other way to
> find a given revision is by date. Git makes it a lot easier, so most
> revisions don't need names.
>
> You can find a full description in the git-rev-parse man page, but here's
> a summary.
This has a lot more overlap with existing documentation. The extra
detail is useful, but we need to decide what our audience and goal is
here, to decide exactly what niche we're trying to fill between the
brief stuff that's in the tutorial part I and the details in
"man git-rev-parse".
> * Converting between names
>
> Git has two helpers (programs designed mainly for use in shell scripts)
> to convert between global object IDs and human-readable names.
>
> The first is git-rev-parse. This is a general git shell script helper,
> which validates the command line and converts object names to absolute
> object IDs. Its man page has a detailed description of the object
> name syntax.
>
> The second is git-name-rev, which converts the other way around. It's
> particularly useful for seeing which tags a given commit falls between.
Also discuss git-describe?
> * The three uses of "git checkout"
Obviously there's a lot of overlap here with "man git-checkout". What's
the goal here? Maybe this should just be worked in to a revision of
that man page?
> * Deleting branches
>
> "git branch -d <head>" is safe. It deletes the given <head>, but first
> it checks that the commit is reachable some other way. That is, you
> merged the branch in somewhere, or you never did any edits on that branch.
It only checks whether the head of the branch to delete is reachable
from the *current* branch. The man page could be clearer here.
....
> * Examining history: git-log and git-rev-list
Yep, we should definitely have a good long chapter just devoted to
history examination. Most of it could be just cool examples, so it
would be fun.
Note some of this is done in the last half of cvs-migration.txt; we
should mine that section for whatever's useful and then replace by a
reference to the new chapter.
> * History diagrams
...
> * Trivial merges: fast-forward and already up-to-date.
These two sections are useful, yep.
> * Exchanging work with other repositories, part II: git-push
There's a lot of overlap here with cvs-migration.txt. Maybe some better
organization is needed to make that more prominent.
> The details are too advanced for this discussion, but the default
> "recursive" merge strategy that git uses solves the answer by merging
> a and b into a temporary commit and using *that* as the merge base.
I'm tempted to ignore any description of the merge strategy, or postpone
it till later; as a first pass I think it's better just to say "obvious
cases will be handled automatically, and you'll be prompted for
comments." Only other SCM developers are going to wonder how you handle
the corner cases.
> * When merging goes wrong
But yes, I think people could use more help on how to resolve merges.
> * Test merging
...
> * Cherry picking
...
> * Rebasing
Yup, I agree that that's good material to cover together.
^ permalink raw reply
* Re: multi-project repos (was Re: Cleaning up git user-interface warts)
From: Marko Macek @ 2006-11-17 17:50 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20061117171532.GE32597@spearce.org>
Shawn Pearce wrote:
> Carl Worth <cworth@cworth.org> wrote:
>> Yes, this was my exact thought when reading what Linus
>> wrote. ORIG_HEAD might be fine and all, but it pales in functionality
>> compared to what reflog provides.
>>
>> I would very much like to see reflog getting first-class citizen
>> support in git:
>>
>> 1. Be on by default
I agree.
> I have:
>
> git repo-config --global core.logAllRefUpdates true
>
> especially since Junio fixed it to only create logs for heads and
> not tags. That way its on by default for me. But I think it should
> be on by default in the next version of Git.
Why is it not useful for tags for having logs?
I also have a question:
Does git-fsck-objects/prune check the ref logs?
Mark
^ permalink raw reply
* [RFC] gitweb TODO
From: Jakub Narebski @ 2006-11-17 18:01 UTC (permalink / raw)
To: git
These are a few gitweb issues and features I'm currently working on
(or plan working on).
1. New patchset view (commitdiff, blobdiff)
In "old" gitweb commitdiff view was generated by iterating over lines of
git-diff-tree raw format output, and generating diffs using
git-cat-file and external diff utility (/usr/bin/diff). This required
having temporary directory for diff generation, and of course diffs
didn't have extended git headers.
The "new" commitdiff view is generated from single git-diff-tree
--raw-with-path output. But I have made incorrect assumption that one
line from "raw" diff-tree output always corresponds to only one patch
in the patchset part of output. This is not the case. I'm not sure if
those are the only cases when patch is broken, but changing file into
symlink or symlink into file ('T' status), and explicit breaking ('B'
status) generates two patches to one line of raw difftree output. The
second is not of much importance for gitweb, unless yoy add -B to
@diff_opts, but the first is important; it is currently broken, see
http://tinyurl.com/y3cfop
(commit 4c52c0d31f0f7142d81a465c40789befc2e86548 on
gitweb-test-funny-char branch in git.git repository).
I have thought of the following (mutually exclusive) ways to fix this
a. Change core git git-diff-tree command to not break (some?) of T
changes into two patches. From what gitster said on #git this
feature is for git-diff patches to be patch(1) compatibile; but
-M already causes patches to be incompatibile with patch. I'm
thinking here about adding some kind of -s/--single-patch
--do-not-break-patch-into-two-please command line option for
git-diff
b. Check the raw difftree line for status and perhaps other info
to know if the line generates more than one patch. It needs detailed
knowledge about _when_ git-diff generates more than one patch to one
"raw" format line, and would break if core diff changes in that
detail. Simplest to implement, I think...
Could you tell me all the cases when git generates more than one
patch for one "raw" diff format line, please?
c. "Cache" git diff header, or the whole patch, or the whole patchset.
It is enough to cache (write lines to "buffer"/"cache" array) up to
the extended header "^index" line, which can be used to check if to
go to the next dofftree "raw" line (or wven which of "raw" difftree
lines this particular patch corresponds to). Does not require
changes in diff core, and is less fragile, less susceptible to
breakage.
Which of those would be the best to implement?
2. Difftree combined diff gitweb "raw" format
Currently "commitdiff" view consist of the gitweb representation of
"raw" git-diff output (list of changed files a la git-whatchanged), and
the patchset (a la git-show). "commit" view has only list of changed
files, nearly exacttly the same as in "commitdiff" view (but with links
to blobdiff view instead of links to appropriate patch in "commitdiff"
view).
I have though about using one of the combined diff outputs for merge
commits. The problem is how to represent the whatchanged part. Which
parts of gitweb difftree output to leave? And what about the fact that
we have raw output for -c/--combined diff format, but not for chunk
simplifying --cc (compact combined) output?
3. Committags support (and implementation)
There was some proposed implementation here, both by me and by Junio,
but no definite patches were accepted. We have the following mutually
exclusive ways to do this:
a. Do esc_html first, then do all committags simultaneously. The
advantage is that it is perhaps slightly faster, the disadvantages
is additional complication in code, and the fact that regexp
defining committags have to be either on esc_html-ed pattern, or be
converted to esc_html-ed input.
b. Have a chain of committags, and do committags sequentially. This
means that we have to divide output into part to be further parsed,
and the part which should not be parsed further; here Junio proposed
wondefull idea of list mixed of strings (to be committags parsed)
and string references (to be left as is). As the last "committag"
we perform esc_html (uless for example some project stores commit
messages in HTML, XML, or some structured text like AsciiDoc or
reStructuredText).
Which of those would be better to implement?
4. Feeds (RSS, Atom,...)
There is new Atom format feed, there was request for per-branch feeds.
The feed output certainly needs cleanup. The questions are:
a.) What should be in the feed (only commit message + authorship, or
also whatchanged; what format use for whatchanged; do add information
about tags created with given window of time, etc.)?
b.) Should we use "text/xml" or (unstandarized) "application/rss+xml" as
type/Content-Type for RSS 2.01 format, should we use
"application/atom+xml" for Atom format?
c.) Should we add APP (Atom Publishing Protocol) support in addition to
OPML?
d.) Should we put log, shortlog, history, rss, atom views together in
one subroutine, and select the view using $format parameter of this
subroutine?
--
Jakub Narebski
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Jakub Narebski @ 2006-11-17 18:16 UTC (permalink / raw)
To: git
In-Reply-To: <20061117174446.GB11882@fieldses.org>
J. Bruce Fields wrote:
> This has some useful material that fills gaps in the existing
> documentation. We need to think a little more about the intended
> audience, and about how to fit it in with existing documentation.
>
> On Thu, Nov 16, 2006 at 05:17:01PM -0500, linux@horizon.com wrote:
>> * A brief digression on command names.
> But the case I'm most interested in is the user whose
> distribution installs git for them, in which case I think the above
> could be distilled down to:
>
> - "git-foo" and "git foo" can be used interchangeably.
But it is encouraged (also for example by git-completion.bash) to use
"git foo" form in command line (because git commands can be not in the PATH,
although usually they are), and "git-foo" form in scripts (if possible).
>> The details are too advanced for this discussion, but the default
>> "recursive" merge strategy that git uses solves the answer by merging
>> a and b into a temporary commit and using *that* as the merge base.
>
> I'm tempted to ignore any description of the merge strategy, or postpone
> it till later; as a first pass I think it's better just to say "obvious
> cases will be handled automatically, and you'll be prompted for
> comments." Only other SCM developers are going to wonder how you handle
> the corner cases.
See below...
>> * When merging goes wrong
>
> But yes, I think people could use more help on how to resolve merges.
It would be useful to cover all non-reductible cases of recursive merge
strategy (the default merge strategy for two-head merges) conflicts:
contents (covered), add/add, rename/modify etc.
So some info about recirsive merge strategy would be useful.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: J. Bruce Fields @ 2006-11-17 18:21 UTC (permalink / raw)
To: Theodore Tso; +Cc: linux, git
In-Reply-To: <20061117153246.GA20065@thunk.org>
On Fri, Nov 17, 2006 at 10:32:46AM -0500, Theodore Tso wrote:
> Personally, I think this information is actually more important to an
> end-user than the current "part two" of the tutorial, which discusses
> the object database and the index file. Perhaps this should be "part
> 2", and the object database and index file should become "part 3"?
Yeah, the really difficult problem here is figuring out how to organize
the documentation. There are a few needs:
1. Quick-start/task-based documentation
- We want to "sell" git to the beginning user by getting
them up and running as quickly as possible.
- We need to help people with some limited needs--
testers who just need to download the latest linux git
tree, or bisect, or whatever.
- It's also a fun way to demonstrate the richness of
some git features (e.g. history explanation).
2. Conceptual background
- People need to understand the commit graph, branches,
merging, the index file (gack), pack files, etc.--some of
that can be put off a little while, some of it can't.
3. Reference documentation
The man pages do most of #3, but maybe they could be better organized--I
think people aren't finding stuff there that they should be.
Numbers 1 and 2 are scattered around git(7), the two-part tutorial, the
git-core tutorial, etc.
> It might also be a good to consider moving some of the "discussion"
> portion the top-level git(7) man page into the object database and
> index file discussion. Right now, the best way to introduce git's
> concepts (IMHO), is to start with the part 1 of the tutorial, then go
> into the your draft branch/merging with git, then the current part 2
> of the tutorial, and then direct folks to read the "discussion"
> section of git(7). Only then do they really have enough background
> understanding of the fundamental concepts of git that they won't get
> confused when they start talking to other git users, on the git
> mailing list, for example.
>
> It would be nice if there was an easy way to direct users through the
> documentation in a way which makes good pedagogical sense. Right now,
> one of the reasons why life gets hard for new users is that the
> current tutorials aren't enough for them to really undersatnd what's
> going on at a conceptual level. And if users start using "everyday
> git" as a crutch, without the right background concepts, the human
> brain naturally tries to intuit what's happening in the background,
> but without reading the background docs, git is different enough that
> they will probably get it wrong, which means more stuff that they have
> to unlearn later.
I agree. Unfortunately, people who need to use git but aren't
study-the-manual-first types *are* going to just dive in whether we want
them to or not, so we have to make it easy for them to pick up what they
need as they go.
How about this as a strawman "git user's manual" outline:
I. Quick-start: drawn from the tutorial part I and everyday.txt?
II. Basic git concepts, drawn from "discussion" in git(7) (the
README), tutorial part II, this branching-and-merging tutorial, etc.:
1. The commit graph and the object database
2. References
3. Fetching and pulling, remotes
4. The index file
III. Using git:
1. History exploration
2. merge resolution
3. pack files, fsck, repository maintenance
4. pushing, setting up a public repo
IV. Advanced examples: drawn from the howto directories,
cvs-migration.txt,...
1. More complicated commandline magic, scripting
(history exploration with git-rev-list, etc.)
2. History re-writing: cherry-picking, rebasing,...
3. Setting up a shared public repo?
4. Migration to/from other SCM's.
IV. Technical details: core-tutorial.txt, plumbing, code tours, etc.
Chapter II is the prerequisite for everything else, so a lot of thought
has to be given to treating exactly what's necessary there and no more.
Maybe more of it could be mixed into chapter I.
It has to be readable in order by the 10% of people who actually like to
read manuals, and easy to pick up in the middle for the 90% who will
just dive into the section they were told they need to read to
understand some particular problem.
In particular, ideally only I and II would really be sequential, and
the rest would be readable in any order.
^ permalink raw reply
* Re: [RFC] gitweb TODO
From: Junio C Hamano @ 2006-11-17 19:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611171901.40839.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> These are a few gitweb issues and features I'm currently working on
> (or plan working on).
>
> 1. New patchset view (commitdiff, blobdiff)
>
> c. "Cache" git diff header, or the whole patch, or the whole patchset.
> It is enough to cache (write lines to "buffer"/"cache" array) up to
> the extended header "^index" line, which can be used to check if to
> go to the next dofftree "raw" line (or wven which of "raw" difftree
> lines this particular patch corresponds to). Does not require
> changes in diff core, and is less fragile, less susceptible to
> breakage.
This is the most appropriate. Right now it is not independently
controllable but it is not so inplausible for somebody to want
to get non recursive view of 'raw' part along with textual diffs
when running "--raw -p" diff and your solution c. is robust
against even such changes.
I would probably not call that "caching" but keeping track of
where you are, and you would need to know in which filepair you
are in anyway when you want to implement links to blob view from
the hunk header lines.
> 2. Difftree combined diff gitweb "raw" format
>...
> I have though about using one of the combined diff outputs for merge
> commits. The problem is how to represent the whatchanged part. Which
> parts of gitweb difftree output to leave? And what about the fact that
> we have raw output for -c/--combined diff format, but not for chunk
> simplifying --cc (compact combined) output?
I am not sure what's more useful to show there. The part of the
output shows "the list of files that have changed by this
commit" for non-merge commits, so "the list of files that have
changed in this merge" is what you would want to show, but there
are three ways you can define "what changed" for a merge (see
the message that explains --cc to linux@horizontal I sent
yesterday). I find "diff --name-status $it^1 $it" the most
natural semantics for the most of the time, and that is what we
do for --stat output.
If you want to treat all the parents equally, you could read
from "diff-tree -c --raw $it" which would show list of files
that needed file-level merges, along with the blob object names
from all parents.
We might want to give that when "diff-tree --cc --patch-with-raw
$it" is asked for in the "raw" part. I dunno.
> 3. Committags support (and implementation)
>...
> Which of those would be better to implement?
I think that is a minor implementation detail; I think the
latter is probably less painful to maintain in the longer run
because if you encode things in earlier stages, postprocessing
stages need to know which part of the result from the earlier
processing needs decoding before further processing, but I
suspect you will be the one primarily hacking on that part, so
it is not my preference, but just a suggestion to make your life
less painful.
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Jon Loeliger @ 2006-11-17 19:24 UTC (permalink / raw)
To: Christian MICHON; +Cc: Git List
In-Reply-To: <46d6db660611131341x40b1fea5m64818cc6ff67c7e2@mail.gmail.com>
On Mon, 2006-11-13 at 15:41, Christian MICHON wrote:
> On 11/13/06, Jon Loeliger <jdl@freescale.com> wrote:
> > All of my git papers published in Linux Magazine as well
> > as my OLS presentation are available off of www.jdl.com.
> > (Yes, I still need to make them available off of
> > opensource.freescale.com as well still. *sigh*)
> >
>
> excellent articles :)
Thank you!
> glad to see other people from the semiconductor industry
> use/excel with git.
For the record, no MS products were used in the
creation of those papers, nor the presentations.
I wrote plain ASCII text for the papers, and the
presentation was done in OpenOffice. After that,
however, I don't know how Linux Magazine produced
the PDF files for the articles. :-)
jdl
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Jon Loeliger @ 2006-11-17 19:31 UTC (permalink / raw)
To: Christian MICHON; +Cc: Git List
In-Reply-To: <1163791447.4665.293.camel@cashmere.sps.mot.com>
On Fri, 2006-11-17 at 13:24, Jon Loeliger wrote:
> > glad to see other people from the semiconductor industry
> > use/excel with git.
>
> For the record, no MS products were used
Yes, I _know_ you meant "do well", not "Use MS Excel"... :-)
jdl
^ permalink raw reply
* Re: multi-project repos
From: Junio C Hamano @ 2006-11-17 20:24 UTC (permalink / raw)
To: Marko Macek; +Cc: git
In-Reply-To: <455DF676.3090001@gmx.net>
Marko Macek <marko.macek@gmx.net> writes:
> Shawn Pearce wrote:
>...
>> I have:
>>
>> git repo-config --global core.logAllRefUpdates true
>>
>> especially since Junio fixed it to only create logs for heads and
>> not tags. That way its on by default for me. But I think it should
>> be on by default in the next version of Git.
>
> Why is it not useful for tags for having logs?
When I make a tag that says "this is the v1.2.0 release", it is
expected it won't change in the future, ever. I _can_ make
mistake and tag a wrong commit under v1.2.0 name, in which case
I may have to replace it with another corrected tag, but
recoding that mistake does not really add value. So most of the
time ref-log for a tag would contain only one entry per file, its
creation, but that creation time is already recorded in the tag
object itself anyway.
At times, it may be useful to have some floating tag that point
at the "latest", or "today's", but that use is a minority. For
these minority cases, you can manually create an empty file
under .git/logs/ directory to record their updates.
The configuration mechanism only kicks in when there is no such
existing file to prime the process, and not creating ref-log for
tags by default is the sensible thing to do.
> I also have a question:
>
> Does git-fsck-objects/prune check the ref logs?
They deliberately ignore ref-log for the same reason lost-found
does not drop found refs under .git/refs hierarchy.
This only matters if you somehow rewind an existing branch in
order to lose part of its history, using "reset --hard HEAD~n"
or "rebase". If the updates to your branch tips always build on
top of the previous (either by commiting on top of the current,
merging on top of the current, or fast-forwarding), and if you
never rewind the branch, the commits recorded in the ref-log for
the branch are always ancestors of the tip of the branch, so
checking ref-log does not give you anything other than slowing
the operation down.
However, if you rewind the tip of a branch, the story changes.
Until the next "prune", objects reachable from the ref-log of
the branch but not reachable from the tip of the branch are
still available in your object store and in a pinch you can
recover them, but after a "prune" they will be lost forever if
they do not have any other references. So it might seem that
they should be protected from pruning.
But if you did so, you can never remove cruft from your object
store once you make a mistake. You can clean up your history by
a reset and/or a rebase, and cleaning up to _lose_ part of the
history was the reason you rewound the branch in the first
place.
In other words, running 'prune' is a conscious act of saying "I
know I am not in the middle of something; I thought over what
I've done recently, salvaged necessary bits from what I
discarded earlier, and there is nothing that need to be salvaged
later anymore -- I have refs to what I need. Now go clean up
the cruft from my object store".
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Junio C Hamano @ 2006-11-17 20:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1163791447.4665.293.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> For the record, no MS products were used in the
> creation of those papers, nor the presentations.
I thought I saw somebody running an OpenOffice presentation on a
windows machine at OLS, and have a vague recollection that it
was you ;-).
^ permalink raw reply
* Re: [RFC] gitweb TODO
From: Jakub Narebski @ 2006-11-17 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt5tlvy5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> These are a few gitweb issues and features I'm currently working on
>> (or plan working on).
>>
>> 1. New patchset view (commitdiff, blobdiff)
>>
>> c. "Cache" git diff header, or the whole patch, or the whole patchset.
>> It is enough to cache (write lines to "buffer"/"cache" array) up to
>> the extended header "^index" line, which can be used to check if to
>> go to the next dofftree "raw" line (or wven which of "raw" difftree
>> lines this particular patch corresponds to). Does not require
>> changes in diff core, and is less fragile, less susceptible to
>> breakage.
>
> This is the most appropriate. Right now it is not independently
> controllable but it is not so inplausible for somebody to want
> to get non recursive view of 'raw' part along with textual diffs
> when running "--raw -p" diff and your solution c. is robust
> against even such changes.
What about the fact that git-diff -M is _not_ patch-compatibile;
does creating two patches for one difftree raw format line for
mode change/'T' status (I guess only for "type" mode changes, i.e.
file to/from symlink, file to/from directory) helps understanding
the change? If not, perhaps it would be better to introduce option
to not break the patch...
> I would probably not call that "caching" but keeping track of
> where you are, and you would need to know in which filepair you
> are in anyway when you want to implement links to blob view from
> the hunk header lines.
I'd say "buffering" rather than "caching". The problem is that
you have to read up to the "index <hash>..<hash>[ <mode>]" to
check if you have to go to the next raw difftree line or not.
And the info from difftree line is needed to hyperlink parts
of extended git diff header (and also to hyperlink parts of
patch).
>> 2. Difftree combined diff gitweb "raw" format
>>...
>> I have though about using one of the combined diff outputs for merge
>> commits. The problem is how to represent the whatchanged part. Which
>> parts of gitweb difftree output to leave? And what about the fact that
>> we have raw output for -c/--combined diff format, but not for chunk
>> simplifying --cc (compact combined) output?
>
> I am not sure what's more useful to show there. The part of the
> output shows "the list of files that have changed by this
> commit" for non-merge commits, so "the list of files that have
> changed in this merge" is what you would want to show, but there
> are three ways you can define "what changed" for a merge (see
> the message that explains --cc to linux@horizontal I sent
> yesterday). I find "diff --name-status $it^1 $it" the most
> natural semantics for the most of the time, and that is what we
> do for --stat output.
>
> If you want to treat all the parents equally, you could read
> from "diff-tree -c --raw $it" which would show list of files
> that needed file-level merges, along with the blob object names
> from all parents.
We should have whatchanged part corresponding to the patchset
part at least in "commitdiff" view, which means '-c' (and for
the time being perhaps mean '-c' also in patchset part). '--cc'
which uses '-c' for the raw part would be nice...
"Commit" view could use "diff --name-status $hash^1 $hash",
(i.e. I think the same what it does now), even if it is not
compatibile with "commitdiff" view.
--
Jakub Narebski
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Steven Grimm @ 2006-11-17 20:30 UTC (permalink / raw)
To: git
In-Reply-To: <87d57pu4qa.wl%cworth@cworth.org>
Jumping into this a day late, but:
Carl Worth wrote:
> I don't see any defining difference that justifies cogito's
> existence ("hide the index" maybe? let's just hide it a tiny bit more
> in git). And I would like to help work to get the remaining good
> stuff that has been proven in cogito---to get it pushed down into git
> itself.
>
Agreed totally on the second point. It would be great if git natively
supported everything people use in Cogito.
I find myself using native git commands for the most part, except for
one Cogito command: "cg-update". It is vastly more convenient than
git-pull in large part because it automatically merges upstream changes
with uncommitted working-copy changes. I suppose you could classify this
as "hide the index" in some sense.
Maybe I should give an example of what I mean. Suppose I have two child
repositories (owned by different developers, say):
cg-clone repo child1
cg-clone repo child2
Now I go into both of them and make different (hopefull non-conflicting)
edits to the same file.
echo foo >> child1/testfile
perl -pi -e 's/tree/shrub/' child2/testfile
I push the change from child1 into the integration repo.
cd child1
git-commit -a
git-push
Now I want to incorporate the change into child2, where I'm still doing
work. With Cogito, I go to child2 and run:
cg-update
and afterwards, the upstream changes are merged into testfile and "git
diff" still shows my local edits. With Git native commands, updating
child2 if I'm not ready to commit yet is more like:
git-diff --binary > /tmp/patch
git-reset --hard
git-pull
git-apply /tmp/patch
I might have gotten that slightly wrong, but I think I have the general
idea right; in any event, it's not nearly as convenient! The alternative
is to commit then pull, but then when I want to look at my local edits,
I have to remember to diff my working copy against the correct revision,
which gets increasingly annoying if I update more than once.
Like others on this list, I'm also trying to sell an existing user base
(in this case, they're using Subversion) on Git. The lack of a built-in
equivalent to "svn update" is actually a pretty big UI annoyance for
people whose workflow doesn't require git's more sophisticated feature
set at a given point in time. Even a sophisticated user doesn't need the
full power of the tool 100% of the time, so this isn't just a novice vs.
expert thing in my opinion.
Absent Cogito, would the lack of a simple "svn update" equivalent be a
deal-killing "throw your hands up in disgust and give up" thing? Maybe
not, but it's a daily "ugh, why am I having to type extra commands to do
something that only took one command in svn?" thing. So it's nice to
have Cogito to paper over that particular wart.
If there is a native git equivalent to cg-update including the
working-copy automatic merges, I'll be delighted to stand corrected!
^ permalink raw reply
* Re: [RFC] gitweb TODO
From: Junio C Hamano @ 2006-11-17 21:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611172130.11631.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> What about the fact that git-diff -M is _not_ patch-compatibile;
What about it? I've never said patch compatibility is an issue.
We have something patch cannot represent or understand and you
should admit it. The point is to make it easier to massage by
hand, when the recipient does not have git handy.
With -M, the recipient can read and understand the patch text
better than "remove this oldfile and create this newfile that
the diff output does not tell you is related" diff. And we say
"rename" in plain language so the recipient _can_ do "mv A B"
then "patch -p1". Similarly, with -T that changes a symlink
into a real file, if we do not do the current "remove the old
and then create the new" and did instead "show the textual diff
that can be applied", a non-git tool that does not understand
the typechange can mistakenly muck with the target of the
symlink, which is a disaster. "Remove the target and then
create this" at least would have lesser damage -- the object
left as the result is incorrect nevertheless, but reading the
contents and creating a symlink that has that contents by hand
is easily done in a pinch.
> We should have whatchanged part corresponding to the patchset
> part at least in "commitdiff" view, which means '-c' (and for
> the time being perhaps mean '-c' also in patchset part). '--cc'
> which uses '-c' for the raw part would be nice...
I am not sure what you mean by patchset part, but if you are
talking about the multiway diff text, I think most of the time
output from "-c -p" is much less interesting than "--cc".
^ permalink raw reply
* Re: git-svn bug?
From: Troy Telford @ 2006-11-17 21:17 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20061117085509.GA29644@localdomain>
On Fri, 17 Nov 2006 01:55:10 -0700, Eric Wong <normalperson@yhbt.net>
wrote:
> dcommit expects to be run on a git-svn fetch-ed HEAD that is linear
> superset of remotes/git-svn. That is: remotes/git-svn..HEAD should
> (ideally) contain no merges, and no root commits. git-svn currently
> does no checking for root commits, but it should.
>
> This commit is missing the git-svn-id: line at the bottom. If you
> simply left it out (private svn repository info), can you check that the
> URL in this line is actually for the SVN repository you want to commit
> to?
I didn't remove anything, but I did double-check and the URL is correct.
But the following may shed light on why there is no git-svn-id anywhere:
IIRC, this is how my current repository came to be (from the very
beginning):
1.) Way back when, before I even started on the project, it started life
as a CVS repository
2.) Was converted from CVS -> SVN in early '05 (pre-git)
3.) I converted from SVN->git in Nov/Dec '05 (using git-svnimport. I'm
not sure git-svn was available at the time.)
4.) The svn repository is still around, and I need to interoperate with
the svn repository on occasion. I read about the new (at the time)
'git-svn', and decided to give it a try.
5.) I start with my pre-existing git repository, running:
git svn init <url>
git svn fetch
git checkout -b master svn
git rebase remotes/git-svn
> It seems like your usage of dcommit would actually cause the issue
> you're experiencing to be triggered on the dummy repository, and not the
> real one. My other guess would be that you somehow merged commits from
> your dummy svn repo into your master branch.
I need to work on being more clear; sorry about that. Here's what I did
with my 'dummy' repository
1. create a new (empty) svn repository
2. imported it into a new git repository using git-svn
3. added a few files that were just sitting in $HOME, then modified them,
removed some, added others, etc. (using both git-svn and subversion)
4. verified everything was working as I expected it to. (and if not,
figure out why I was wrong).
My 'dummy' repo was imported using git-svn.
My 'real' repo was imported using git-svnimport.
Having not read any of the code, I'm just taking a wild guess; but is it
reasonable to say that since the repository was originally imported to git
using git-svnimport (rather than git-svn), git-svn doesn't have some of
the data it needs to push to the remote svn repo?
Would it be reasonable to use git-svn to import the SVN repository into a
new git repo, and then rebase from the old git-svnimport'ed repo into the
new git-svn imported one? (did that even make sense?!?)
--
^ permalink raw reply
* Re: [RFC] gitweb TODO
From: Jakub Narebski @ 2006-11-17 21:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu00xixxk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> What about the fact that git-diff -M is _not_ patch-compatibile;
>
> What about it? I've never said patch compatibility is an issue.
> We have something patch cannot represent or understand and you
> should admit it. The point is to make it easier to massage by
> hand, when the recipient does not have git handy.
>
> With -M, the recipient can read and understand the patch text
> better than "remove this oldfile and create this newfile that
> the diff output does not tell you is related" diff. And we say
> "rename" in plain language so the recipient _can_ do "mv A B"
> then "patch -p1". Similarly, with -T that changes a symlink
> into a real file, if we do not do the current "remove the old
> and then create the new" and did instead "show the textual diff
> that can be applied", a non-git tool that does not understand
> the typechange can mistakenly muck with the target of the
> symlink, which is a disaster. "Remove the target and then
> create this" at least would have lesser damage -- the object
> left as the result is incorrect nevertheless, but reading the
> contents and creating a symlink that has that contents by hand
> is easily done in a pinch.
So we split patch for "type change" mode change for patch -p1
safety. But for gitweb more important than producing safe patch
is producing _readable_ patch[*1*]. Hence request for -T option
(or under other, better name) to git-diff which would _not_
split patch (not create two patches for one raw difftree line).
[*1*] Well, as far as diff for symlink is readable anyway.
>> We should have whatchanged part corresponding to the patchset
>> part at least in "commitdiff" view, which means '-c' (and for
>> the time being perhaps mean '-c' also in patchset part). '--cc'
>> which uses '-c' for the raw part would be nice...
>
> I am not sure what you mean by patchset part, but if you are
> talking about the multiway diff text, I think most of the time
> output from "-c -p" is much less interesting than "--cc".
Sorry, perhaps I was not clear. I'd like for git-diff-tree --cc
--raw -p to output both raw part (perhaps taken from -c) and
patch part[*2*]. Gitweb needs raw part for both whatchanged
and also for creating hyperlinks and gitweb quoted filenames
in the patch part (although with git diff headers buffering
and git diff extended headers parsing we could get the information
needed for hyperlinks and gitweb quoting of filenames for patch
part from patch part).
[*2*] I'm wondering why we don't have --patch long version of -p
option to git-diff[-tree].
--
Jakub Narebski
^ permalink raw reply
* Re: [DRAFT] Branching and merging with git
From: Petr Baudis @ 2006-11-17 21:31 UTC (permalink / raw)
To: Sean; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20061117120154.3eaf5611.seanlkml@sympatico.ca>
On Fri, Nov 17, 2006 at 06:01:54PM CET, Sean wrote:
> There is enough native Git documentation and hopefully more coming
> that third party tools should be pushed behind the scenes a bit.
> At least on the GIT website.
It's not about documentation but ease to use. I agree and sympathise
very much with the effort of making core Git more easy to use and
obsoleting Cogito, but until it gets there we should have what's nicest
to the users.
> Of course there is nothing wrong with having information there, but
> the main thrust should be about Git and how to use it directly without
> porcelains. Especially in the light that people have recently
> expressed a desire to advocate and document the use of native Git
> more strongly.
If someone writes a crash course in pure Git covering the same grounds
as the current ones (possibly by just extending/retouching the tutorial)
(it does not necessarily need to be a "refugee" crash course, it can
build up from scratch), I can add it on the web. If it becomes as easy
to use and with as mild learning curve as Cogito, it means Cogito got
mostly obsolete and I'll happily remove the Cogito crash courses from
the web.
> Having a link to Cogito off the front page of the Git website that
> says... Cogito makes things "easier", no matter how much you
> personally believe it, isn't the way everyone feels and is at
> odds with the native-git message and improvement effort.
If you disagree about that fact, can you provide some specific
argumentation?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-17 21:35 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <455E1BF1.1030003@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> echo foo >> child1/testfile
> perl -pi -e 's/tree/shrub/' child2/testfile
>...
> git-diff --binary > /tmp/patch
> git-reset --hard
> git-pull
> git-apply /tmp/patch
>
> I might have gotten that slightly wrong, but I think I have the
> general idea right.
stg pull would help you in such a situation as well, but I see
what you mean.
Just like we have an explicit -m option to "checkout" to allow
file-level merging of local changes, I think it is reasonable to
hav an option that allows file-level merging of local changes
when doing a pull that you _know_ will not conflict.
When there will be a conflict between your HEAD and MERGE_HEAD
even without your local changes, you somehow need to sort out
the resulting mess that come from conflicts due to the branch
diversion (i.e. log HEAD...MERGE_HEAD) and conflicts between
your local change and what the other branch did. The resulting
merge commit obviously needs to record resolutions only to the
former and should not even record anything you did locally,
conflicted or not. Which is a pain for the end user and giving
them a way to revert to the state before this three-and-half
way merge started also needs to be there.
Unfortunately the only way to know if there will be a file-level
conflict is to try one, and stashing away the current state just
in case it conflicted is a performance penalty, so this probably
should stay as an option just like "-m" to the "checkout".
But the basic mechanism to do this three-and-half way merge is
simple and I have no objection if somebody wanted to add such an
option to "git pull".
^ 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