* Re: Cleaning up git user-interface warts
From: Nicolas Pitre @ 2006-11-15 14:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejeotu$vrj$3@sea.gmane.org>
On Wed, 15 Nov 2006, Jakub Narebski wrote:
> Nicolas Pitre wrote:
>
> > On Tue, 14 Nov 2006, Junio C Hamano wrote:
> >
> >> Yes. The current "merge" started its life as Linus's porcelain
> >> (we did not have fetch and pull infrastructure back then) but
> >> quickly has become just a helper for pull to produce a merge
> >> commit. If anybody thinks its UI is good as a general end-user
> >> level command, there is a need for "head examination".
> >
> > If you mean "git merge" it sure needs to be brought forward. It can't
> > be clearer than:
> >
> > git-merge the_other_branch
> >
> > or
> >
> > git-merge git://repo.com/time_machine.git
> >
> > to instantaneously understand what is going on.
>
> You mean
>
> git merge git://repo.com/time_machine.git#branch
>
> don't you (perhaps with 'master' as default branch)?
Something like that. I wantee to enphasize on the "merge" command that
should deal with, hey, merges.
I don't know if # is a good choice for branch indicator though.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Johannes Schindelin @ 2006-11-15 14:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Andy Whitcroft, Carl Worth
In-Reply-To: <7vu011qnl6.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > 1) make "git init" an alias for "git init-db".
>
> Or even better, have "gh init".
Please no. It only makes things even more confusing. "git init" is perfect
as it is. We can always have internal aliases from "init-db" to "init" to
account for older usages.
> > 2) "pull" and "push" should be symmetrical operations
>
> I think that makes a lot of sense to have "gh pull" and "gh
> push" as symmetric operations, and make "gh merge" do the
> fast-forward and 3-way merge magic done in the current "git
> pull". These three words would have a lot saner meaning.
I am really opposed to do "gh pull". Not only because of "gh" being
completely confusing (we already _have_ "git", and for porcelains
different TLAs), but "pull" _really_ is confusing by now. And Mercurial
did not help one wit by insisting on their own interpretation.
Why not do something like "get/put" instead? It is
- easier to remember
- not bogus (AFAICT the meaning is not used in diametrical senses)
- shorter to type than download/upload
As for "git merge": Just by the number of arguments you can discern
between the original usage and the new usage, so I am all in favour of
replacing "git pull <blabla>" by "git merge <blabla>". Where "<blabla>"
can be a branch or a remote or a URL (with cogito style #branchname).
Ciao,
Dscho
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-15 12:31 UTC (permalink / raw)
To: git
In-Reply-To: <455B04DE.1040107@op5.se>
Andreas Ericsson wrote:
> Nicolas Pitre wrote:
>
> [ axed a lot of stuff that I didn't fully grok ]
>
>>
>> This becomes formalized as:
>>
>> git_pull [<URL>] [<local_name>]
>>
>> If <URL> includes a branch name then <local_name> is a single branch
>> name. If <URL> doesn't include any branch name then <local_name>
>> becomes a local branch group name containing all branches in the remote
>> repository.
>
> I would change that so "local_name" is always a branch group name, but
> branch group names can be used as refs. That is,
>
> git pull startrek.com/kirk.git:master kirk
I'd rather use Cogito (not gitweb) notation startrek.com/kirk.git#master
This way we can change the name of local branch
startrek.com/kirk.git#master:kirk
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Andreas Ericsson @ 2006-11-15 12:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Andy Whitcroft, Carl Worth
In-Reply-To: <Pine.LNX.4.64.0611142048350.2591@xanadu.home>
Nicolas Pitre wrote:
[ axed a lot of stuff that I didn't fully grok ]
>
> This becomes formalized as:
>
> git_pull [<URL>] [<local_name>]
>
> If <URL> includes a branch name then <local_name> is a single branch
> name. If <URL> doesn't include any branch name then <local_name>
> becomes a local branch group name containing all branches in the remote
> repository.
I would change that so "local_name" is always a branch group name, but
branch group names can be used as refs. That is,
git pull startrek.com/kirk.git:master kirk
would always create the branch-head .git/refs/remote/kirk/master which
for short can be referenced as just "kirk" (barring clashes ofc), so
long as it only has one branch tracked.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Andy Parkins @ 2006-11-15 11:28 UTC (permalink / raw)
To: git
In-Reply-To: <20061115104858.GG5453@diana.vm.bytemark.co.uk>
On Wednesday 2006 November 15 10:48, Karl Hasselström wrote:
> To me, "origin" just means "where <whatever we're talking about>
> originated". If you think of it that way, it's perfectly obvious that
> each repository can have its own origin.
Of course. I wasn't saying that I didn't understand why origin was chosen.
It's not a completely crazy name - it does have /a/ meaning. However, it's
not an unambiguous meaning. What if the repository I clone was itself a
clone? What if the repository it cloned was pulling from three other
repositories? What if those three repositories pull/push from/to each other?
* -- * -- *
\ | / \
\ | / /
\ | / /
* /
| /
| /
* <--- "origin"
|
* <--- cloned repository
The name "origin" is too close to having an "ultimate source" feel to it IMO.
In a distributed system, it's not the right idea to be pushing. After the
clone is complete, the "origin" is no more special than any other repository,
and if you felt like it you could change the URL for "origin" and it would
make very little difference to you.
In short: I don't think "origin" is wrong, I just think it's not right.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH 3/5] allow cloning a repository "shallowly"
From: Johannes Schindelin @ 2006-11-15 10:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsbpzzse.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 14 Nov 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> I understand "no need making it shallow", but I am not sure if a
> >> non-NULL return from lookup_object() tells us that.
> >
> > You are probably right, how about has_sha1_file()?
> >
> >> I think register_shallow() can take commits that are already shallow()
> >> so maybe we can remove this "if() continue"?
> >
> > Yes, it can, but that is not necessarily correct: since .git/shallow is
> > constructed from the registered shallow commits, we would make a commit
> > shallow which is really not shallow.
> >
> > So, how about
> >
> >> > + if (lookup_object(sha1) || has_sha1_file(sha1))
> >> > + continue;
>
> If I understand the code correctly, this loop is reading what
> the other side thinks your shallows should be (based on your
> earlier "deepen" request or if this is initial fetch based on
> your depth). Even if we already have that object, if that
> object _is_ shallow on our end, don't we need to keep it marked
> as shallow? Will we get ancestors of this commit from the other
> end (and "shallow" lines for some of them to properly cauterize
> the chain)?
My thinking was: if we have that object already, and it is _not_ marked as
shallow, we probably have either all its ancestors, or at least all
ancestors up until shallow commit(s).
Thinking about it again, it seems very fragile: on purpose, we only trust
to have the objects which are reachable by at least one ref, so that an
interrupted fetch does not corrupt the repository.
So yes, I agree, that "if() continue;" should go away. Even if all of a
sudden, commits we already have are no longer reachable.
Ciao,
Dscho
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Karl Hasselström @ 2006-11-15 10:48 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611151033.57415.andyparkins@gmail.com>
On 2006-11-15 11:33:55 +0100, Andy Parkins wrote:
> But that is not necessarily /the/ original, and "origin" is the
> absolute reference in maths. It doesn't bother me that much I
> suppose, it's just that as far as unambiguous names go, I'm not wild
> about it - it's got too many "central repository" connotations,
> which is of course anathema to git.
To me, "origin" just means "where <whatever we're talking about>
originated". If you think of it that way, it's perfectly obvious that
each repository can have its own origin.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Andy Parkins @ 2006-11-15 10:33 UTC (permalink / raw)
To: git
In-Reply-To: <ejeocl$vrj$1@sea.gmane.org>
On Wednesday 2006 November 15 09:59, Jakub Narebski wrote:
> > * Don't use the name "origin" twice. In fact, don't use it at all. In
> > a distributed system there is no such thing as a true origin.
>
> The remote 'origin' is true origin of the repository: it is repository
> we cloned this repository from.
But that is not necessarily /the/ original, and "origin" is the absolute
reference in maths. It doesn't bother me that much I suppose, it's just that
as far as unambiguous names go, I'm not wild about it - it's got too
many "central repository" connotations, which is of course anathema to git.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-15 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <8aa486160611150215n64bb01e6o49aeaf243ad8f817@mail.gmail.com>
Santi Béjar wrote:
> On 11/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> You mean
>>
>> git merge git://repo.com/time_machine.git#branch
>>
>> don't you (perhaps with 'master' as default branch)?
>
> perhaps with remote 'HEAD' as default branch?
No! HEAD might change without your notice, and you want to know
which branch you merge. With remotes the default could be first
branch in the pull/fetch list, but with bare URL...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Karl Hasselström @ 2006-11-15 10:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejeomr$vrj$2@sea.gmane.org>
On 2006-11-15 11:05:26 +0100, Jakub Narebski wrote:
> The problem is that one man's plumbing is another man porcelain.
No; that way lies insanitation.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Santi Béjar @ 2006-11-15 10:15 UTC (permalink / raw)
To: git
In-Reply-To: <ejeotu$vrj$3@sea.gmane.org>
On 11/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Nicolas Pitre wrote:
>
> > On Tue, 14 Nov 2006, Junio C Hamano wrote:
> >
> >> Yes. The current "merge" started its life as Linus's porcelain
> >> (we did not have fetch and pull infrastructure back then) but
> >> quickly has become just a helper for pull to produce a merge
> >> commit. If anybody thinks its UI is good as a general end-user
> >> level command, there is a need for "head examination".
> >
> > If you mean "git merge" it sure needs to be brought forward. It can't
> > be clearer than:
> >
> > git-merge the_other_branch
> >
> > or
> >
> > git-merge git://repo.com/time_machine.git
> >
> > to instantaneously understand what is going on.
>
> You mean
>
> git merge git://repo.com/time_machine.git#branch
>
> don't you (perhaps with 'master' as default branch)?
perhaps with remote 'HEAD' as default branch?
^ permalink raw reply
* Re: git-svn and rebase causes duplicate log entries in svn
From: Joakim Tjernlund @ 2006-11-15 10:14 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2zmatiqon.fsf@ziti.local>
Seth Falcon wrote:
> Hi Joakim,
>
> "Joakim Tjernlund" <joakim.tjernlund@transmode.se> writes:
>
>> Now I want to rebase my svn branch against latest u-boot and commit
>> my rebased svn branch to svn.
>>
>> I use git-svn commit -b svn -q remotes/git-svn..svn to commit my latest
>> changes and when I do so I see my local changes once more in the svn
>> log:
>> Any way to avoid that?
>>
>
> I think you want to use git-svn dcommit, and not commit. See the
> notes in the git-svn man page. The basic workflow
> that I've been using is:
>
> git-svn fetch
> git rebase remotes/git-svn ## on mybranch
> ## make commits on mybranch
> git-svn dcommit remotes/git-svn..mybranch
>
> This results in each commit that I made on mybranch being sent to svn
> as a separate commit.
>
> + seth
>
Thanks, but for some reson I can't make dcommit work. I just get
git-svn dcommit -q remotes/git-svn..svn
Unable to extract revision information from commit
3643783f1f2fbdec1514b5e842e97b27622ae8b8~1
My workflow is perhaps a little diffrent I do all dev in git and then
commit to SVN.
I start with creating an empty SVN tree and then do a
git-svn commit <commit id where my dev started from u-boot>
then I do a
git-svn commit -q remotes/git-svn..svn
to add all my own commits.
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-15 10:09 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611142342160.2591@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 14 Nov 2006, Junio C Hamano wrote:
>
>> Yes. The current "merge" started its life as Linus's porcelain
>> (we did not have fetch and pull infrastructure back then) but
>> quickly has become just a helper for pull to produce a merge
>> commit. If anybody thinks its UI is good as a general end-user
>> level command, there is a need for "head examination".
>
> If you mean "git merge" it sure needs to be brought forward. It can't
> be clearer than:
>
> git-merge the_other_branch
>
> or
>
> git-merge git://repo.com/time_machine.git
>
> to instantaneously understand what is going on.
You mean
git merge git://repo.com/time_machine.git#branch
don't you (perhaps with 'master' as default branch)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-15 10:05 UTC (permalink / raw)
To: git
In-Reply-To: <20061115040852.GL7201@pasky.or.cz>
Petr Baudis wrote:
> (i) Clearly divided porcelain/plumbing interface, so that you can
> really isolate the two UI-wise; endless confusion reigns there now. Is
> git-update-index porcelain or plumbing? _You_ call git-merge a proper
> porcelain? From my perspective, git-update-ref is as plumbing as it
> gets, but it's classified as porcelain. Etc, etc. This would be by far
> the most important advantage.
The problem is that one man's plumbing is another man porcelain.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Jakub Narebski @ 2006-11-15 9:59 UTC (permalink / raw)
To: git
In-Reply-To: <200611150917.23756.andyparkins@gmail.com>
Andy Parkins wrote:
> * Don't use the name "origin" twice. In fact, don't use it at all. In a
> distributed system there is no such thing as a true origin.
The remote 'origin' is true origin of the repository: it is repository
we cloned this repository from.
I agree that having branch 'origin', at least in most common multi-branch
(multi-head) repository, is just confusing.
> * Ensuring we have /all/ upstream branches at a later date is hard, and not
> automatic. Here is the .git/remotes/default file that should be possible:
> URL: git://host/project.git
> Pull: refs/heads/*:refs/remotes/default/*
> Now, every git-pull would check for new upstream branch refs and sync them
> into the local remotes list. These are read-only so it'd be perfectly safe
> to delete any locally that no longer exist upstream.
Very nice idea.
> * git-clone should really just be a small wrapper around
> - git-init-db
> - create .git/remotes/default
> - maybe create specific .git/config
I'm not sure about "create .git/remotes/default" part. Isn't git moving from
remotes file to having information about remotes (and branches) in config?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Andy Parkins @ 2006-11-15 9:17 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611142048350.2591@xanadu.home>
On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:
> OK..... let's pretend this is my follow-up to your "If I were redoing
Personally, I agree with almost everything in this email. Except the
implementation of point 3.
> 3) remote branch handling should become more straight forward.
I was completely confused by this origin/master/clone stuff when I started
with git. In hindsight, now I understand git a bit more, this is what I
would have liked:
* Don't use the name "origin" twice. In fact, don't use it at all. In a
distributed system there is no such thing as a true origin.
* .git/remotes/origin should be ".git/remotes/default". "origin" is only
special because it is the default to push and pull - it's very nice to have a
default, but it should therefore be /called/ "default".
* Whatever git-clone calls the remote, it should be matched by a directory
in .git/refs/remotes. So .git/remotes/$name contains "Pull"s to get all the
remote branches to .git/refs/remotes/$name/*. This implies that
git /always/ does --use-separate-remote in clone. If a branch is practically
read-only it should be technically read-only too.
* If clone really wants to have a non-read-only master, then that should
be .git/refs/heads/master and will initialise
to .git/refs/remotes/$name/master after cloning. Personally I think this is
dangerous because it assumes there is a "master" upstream - which git doesn't
mandate at all. Maybe it would be better to take the upstream HEAD and
create a local branch for /that/ branch rather than require that it is
called "master".
* Ensuring we have /all/ upstream branches at a later date is hard, and not
automatic. Here is the .git/remotes/default file that should be possible:
URL: git://host/project.git
Pull: refs/heads/*:refs/remotes/default/*
Now, every git-pull would check for new upstream branch refs and sync them
into the local remotes list. These are read-only so it'd be perfectly safe
to delete any locally that no longer exist upstream.
* git-clone should really just be a small wrapper around
- git-init-db
- create .git/remotes/default
- maybe create specific .git/config
- git-fetch default
If git-clone does anything that can't be done with settings in the config
and the remotes/default file then it's wrong. The reason I say this is that
as soon as git-clone has special capabilities (like --shared, --local
and --reference) then you are prevented from doing magic with existing
repositories. For example; how do you create a repository that contains
branches from two other local repositories that have the objects hard linked?
While I'm writing wishes, I'd like to jump on Junio's integration with other
fetch-backends wish. I use git-svn, and it would be fantastic if I could
replace:
git-svn init --id upstream/trunk svn://host/path/trunk
git-svn fetch --id upstream/trunk
git-svn init --id upstream/stable svn://host/path/branches/stable
git-svn fetch --id upstream/stable
With a .git/remotes/svn
SVN-URL: svn://host/path
Pull: trunk:refs/remotes/upstream/trunk
Pull: branches/stable:refs/remotes/upstream/stable
and
git fetch svn
Obviously, the syntax is just made up; but you get the idea. Even better,
would be if it could cope with my "*" syntax suggested above:
SVN-URL: svn://host/path
Pull: trunk:refs/remotes/upstream/trunk
Pull: branches/*:refs/remotes/upstream/*
There have been lots of "wishlist" posts lately; would it be useful if I tried
to collect all these suggestions from various people into one place to try
and get a picture of any consensus?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.4
From: Junio C Hamano @ 2006-11-15 7:43 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest feature release GIT 1.4.4 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.4.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.4.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.4-1.$arch.rpm (RPM)
Quite a lot of changes during the last month.
- pack-refs, along with a lot of internal clean-up of the code
that deal with refs, is in. A repository with many tags
would benefit from packing and pruning them. Currently dumb
transports are not capable of fetching from a repository that
has packed and pruned its refs, so please keep that in mind.
Hopefully we will get an update for dumb transports shortly.
- git native transport can now keep transferred packs without
exploding it into loose objects. Also "git repack" can be
told to keep "historical" packs from getting repacked by
marking them with .keep file. Docmentation update is
probably needed.
- git-blame can now detect line movements across files. No, it
is not called git-pickaxe.
- a lot of gitweb and git-svn updates.
----------------------------------------------------------------
Changes since v1.4.3 are as follows:
Alan Chandler:
Gitweb - provide site headers and footers
Alex Riesen:
merge-recursive implicitely depends on trust_executable_bit
Alexandre Julliard:
git.el: Added a function to open the current file in another window.
git.el: Added functions for moving to the next/prev unmerged file.
git.el: Include MERGE_MSG in the log-edit buffer even when not committing a merge.
git.el: Move point after the log message header when entering log-edit mode.
pack-refs: Store the full name of the ref even when packing only tags.
prune-packed: Fix uninitialized variable.
Andy Parkins:
git-clone documentation didn't mention --origin as equivalent of -o
Make filenames line up in git-status output
Minor grammar fixes for git-diff-index.txt
Remove uneccessarily similar printf() from print_ref_list() in builtin-branch
Andy Whitcroft:
cvsimport: move over to using git-for-each-ref to read refs.
git-for-each-ref: improve the documentation on scripting modes
Aneesh Kumar K.V:
gitweb: Remove extra "/" in path names for git_get_project_list
Christian Couder:
Add pack-refs and show-ref test cases.
Add [-s|--hash] option to Linus' show-ref.
Check that a tag exists using show-ref instead of looking for the ref file.
Clean up "git-branch.sh" and add remove recursive dir test cases.
Documentation: add git in /etc/services.
Documentation: add upload-archive service to git-daemon.
Document git-show-ref [-s|--hash] option.
Do not create tag leading directories since git update-ref does it.
Fix a remove_empty_dir_recursive problem.
Fix show-ref usage for --dereference.
Remove --syslog in git-daemon inetd documentation examples.
Uncomment test case: git branch c/d should barf if branch c exists.
Use git-update-ref to delete a tag instead of rm()ing the ref file.
Use Linus' show ref in "git-branch.sh".
When creating branch c/d check that branch c does not already exists.
Dennis Stosberg:
lock_ref_sha1_basic does not remove empty directories on BSD
Remove bashism from t3210-pack-refs.sh
Bash completion support for aliases
Dmitry V. Levin:
git-clone: define die() and use it.
Edgar Toernig:
Use memmove instead of memcpy for overlapping areas
Eric Wong:
git-send-email: do not pass custom Date: header
git-svn: avoid printing filenames of files we're not tracking
git-svn: don't die on rebuild when --upgrade is specified
git-svn: fix dcommit losing changes when out-of-date from svn
git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
Gerrit Pape:
Set $HOME for selftests
J. Bruce Fields:
Make prune also run prune-packed
Documentation: updates to "Everyday GIT"
Jakub Narebski:
diff-format.txt: Combined diff format documentation supplement
diff-format.txt: Correct information about pathnames quoting in patch format
Documentation: Transplanting branch with git-rebase --onto
Documentation: Update information about <format> in git-for-each-ref
gitweb: Add "next" link to commitdiff view
gitweb: Add '..' (up directory) to tree view if applicable
gitweb: Better git-unquoting and gitweb-quoting of pathnames
gitweb: Better support for non-CSS aware web browsers
gitweb: Check git base URLs before generating URL from it
gitweb: Do not esc_html $basedir argument to git_print_tree_entry
gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff
gitweb: Get rid of git_print_simplified_log
gitweb: Improve git_print_page_path
gitweb: Move git_get_last_activity subroutine earlier
gitweb: New improved patchset view
gitweb: Output also empty patches in "commitdiff" view
gitweb: Print commit message without title in commitdiff only if there is any
gitweb: Secure against commit-ish/tree-ish with the same name as path
gitweb: Use character or octal escape codes (and add span.cntrl) in esc_path
gitweb: Use git-for-each-ref to generate list of heads and/or tags
gitweb: Use --no-commit-id in git_commit and git_commitdiff
gitweb: Use 's' regexp modifier to secure against filenames with LF
gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
Jan Harkes:
Continue traversal when rev-list --unpacked finds a packed commit.
Jeff King:
wt-status: use simplified resolve_ref to find current branch
gitignore: git-pack-refs is a generated file.
gitignore: git-show-ref is a generated file.
git-pickaxe: work properly in a subdirectory.
Fix git-runstatus for repositories containing a file named HEAD
Jim Meyering:
Don't use $author_name undefined when $from contains no /\s</.
git-clone: honor --quiet
xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
Johannes Schindelin:
Fix git-update-index --again
show-branch: mark active branch with a '*' again
Turn on recursive with --summary
link_temp_to_file: call adjust_shared_perm() only when we created the directory
Johannes Sixt:
test-lib.sh: A command dying due to a signal is an unexpected failure.
Catch errors when writing an index that contains invalid objects.
Jonas Fonseca:
Add man page for git-show-ref
git-update-index(1): fix use of quoting in section title
Junio C Hamano:
Add callback data to for_each_ref() family.
Add git-for-each-ref: helper for language bindings
adjust_shared_perm: chmod() only when needed.
apply: handle "traditional" creation/deletion diff correctly.
blame.c: move code to output metainfo into a separate function.
blame.c: whitespace and formatting clean-up.
blame: Document and add help text for -f, -n, and -p
branch: work in subdirectories.
cherry is built-in, do not ship git-cherry.sh
Clean-up lock-ref implementation
combine-diff: a few more finishing touches.
combine-diff: fix hunk_comment_line logic.
combine-diff: honour --no-commit-id
core.logallrefupdates create new log file only for branch heads.
core.logallrefupdates thinko-fix
daemon: do not die on older clients.
delete_ref(): delete packed ref
diff --numstat
Documentation: clarify refname disambiguation rules.
Documentation: fix git-format-patch mark-up and link it from git.txt
Documentation: move blame examples
Documentation: note about contrib/.
Documentation/SubmittingPatches: 3+1 != 6
Document git-pack-refs and link it to git(7).
Fix refs.c;:repack_without_ref() clean-up path
Fix t1400-update-ref test minimally
for-each-ref: "creator" and "creatordate" fields
fsck-objects: adjust to resolve_ref() clean-up.
GIT 1.4.3-rc1
GIT 1.4.4
GIT 1.4.4-rc2
git-annotate: fix -S on graft file with comments.
git-annotate: no need to exec blame; it is built-in now.
git-blame: add internal statistics to count read blobs.
git-blame --porcelain
git-blame: --show-name (and -f)
git-blame: --show-number (and -n)
git-branch: remove D/F check done by hand.
git-cvsserver: read from git with -z to get non-ASCII pathnames.
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 1)
git-fetch: adjust to packed-refs.
git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
git-pack-refs --all
git-pack-refs --prune
git-pickaxe: allow -Ln,m as well as -L n,m
git-pickaxe: allow "-L <something>,+N"
git-pickaxe: blame rewritten.
git-pickaxe: cache one already found path per commit.
git-pickaxe -C: blame cut-and-pasted lines.
git-pickaxe: do not confuse two origins that are the same.
git-pickaxe: do not keep commit buffer.
git-pickaxe: fix nth_line()
git-pickaxe: fix origin refcounting
git-pickaxe: get rid of wasteful find_origin().
git-pickaxe: improve "best match" heuristics
git-pickaxe: introduce heuristics to avoid "trivial" chunks
git-pickaxe: -L /regexp/,/regexp/
git-pickaxe -M: blame line movements within a file.
git-pickaxe: optimize by avoiding repeated read_sha1_file().
git-pickaxe: pagenate output by default.
git-pickaxe: refcount origin correctly in find_copy_in_parent()
git-pickaxe: rename detection optimization
git-pickaxe: re-scan the blob after making progress with -C
git-pickaxe: re-scan the blob after making progress with -M
git-pickaxe: retire pickaxe
git-pickaxe: simplify Octopus merges further
git-pickaxe: split find_origin() into find_rename() and find_origin().
git-pickaxe: swap comparison loop used for -C
git-pickaxe: tighten sanity checks.
git-pickaxe: WIP to refcount origin structure.
git-repack: repo.usedeltabaseoffset
git-send-email: do not drop custom headers the user prepared
git-send-email: real name with period need to be dq-quoted on From: line
git-status: quote LF in its output
gitweb: do not give blame link unconditionally in diff-tree view
gitweb: fix disabling of "forks"
gitweb: fix unmatched div in commitdiff
gitweb: make leftmost column of blame less cluttered.
gitweb: minimally fix "fork" support.
gitweb: prepare for repositories with packed refs.
gitweb: protect blob and diff output lines from controls.
gitweb: protect commit messages from controls.
gitweb: spell "blame --porcelain" with -p
gitweb: use blame --porcelain
gitweb: use for-each-ref to show the latest activity across branches
grep --all-match
Introduce a new revision set operator <rev>^!
link_temp_to_file: don't leave the path truncated on adjust_shared_perm failure
lock_ref_sha1_basic: remove unused parameter "plen".
lock_ref_sha1(): check D/F conflict with packed ref when creating.
lock_ref_sha1(): do not sometimes error() and sometimes die().
Make git-send-email detect mbox-style patches more readily
merge: loosen overcautious "working file will be lost" check.
merge-recursive: adjust to loosened "working file clobbered" check
merge-recursive: make a few functions static.
merge-recursive: use abbreviated commit object name.
pack-objects: document --delta-base-offset option
pack-refs: call fflush before fsync.
pack-refs: do not pack symbolic refs.
pack-refs: fix git_path() usage.
pack-refs: use lockfile as everybody else does.
pager: default to LESS=FRS
pager: default to LESS=FRSX not LESS=FRS
path-list: fix path-list-insert return value
quote.c: ensure the same quoting across platforms.
receive-pack: call setup_ident before git_config
Refer to git-rev-parse:Specifying Revisions from git.txt
ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
ref-log: allow ref@{count} syntax.
ref-log: fix D/F conflict coming from deleted refs.
refs: minor restructuring of cached refs data.
Revert 954a6183756a073723a7c9fd8d2feb13132876b0
Revert "send-pack --keep: do not explode into loose objects on the receiving end."
revision traversal: --unpacked does not limit commit list anymore.
RPM package re-classification.
send-pack --keep: do not explode into loose objects on the receiving end.
sha1_name.c: avoid compilation warnings.
show-ref --hash=len, --abbrev=len, and --abbrev
Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
symbolit-ref: fix resolve_ref conversion.
t3200: git-branch testsuite update
t6022: ignoring untracked files by merge-recursive when they do not matter
Teach receive-pack about ref-log
teach revision walker about --all-match.
Tell between packed, unpacked and symbolic refs.
tests: merge-recursive is usable without Python
update a few Porcelain-ish for ref lock safety.
Update cherry documentation.
update-ref: -d flag and ref creation safety.
Karl Hasselström:
git-vc: better installation instructions
ignore-errors requires cl
Lars Hjemli:
Fix typo in show-index.c
Fix usagestring for git-branch
Make git-branch a builtin
Fix show-ref usagestring
Linus Torvalds:
Add "git show-ref" builtin command
Teach "git checkout" to use git-show-ref
Start handling references internally as a sorted in-memory list
Add support for negative refs
Make ref resolution saner
Enable the packed refs file format
git-apply: prepare for upcoming GNU diff -u format change.
Allow '-' in config variable names
git push: add verbose flag and allow overriding of default target repository
Luben Tuikov:
gitweb: blame: print commit-8 on the leading row of a commit-block
gitweb: blame: Mouse-over commit-8 shows author and date
gitweb: blame porcelain: lineno and orig lineno swapped
git-revert with conflicts to behave as git-merge with conflicts
gitweb: esc_html() author in blame
Martin Waitz:
gitweb: start to generate PATH_INFO URLs.
gitweb: warn if feature cannot be overridden.
Matthew Wilcox:
Add --dry-run option to git-send-email
Nguyễn Thái Ngọc Duy:
Reject hexstring longer than 40-bytes in get_short_sha1()
Add revspec documentation for ':path', ':[0-3]:path' and git-describe
Nicolas Pitre:
introduce delta objects with offset to base
teach git-unpack-objects about deltas with offset to base
teach git-index-pack about deltas with offset to base
make git-pack-objects able to create deltas with offset to base
make pack data reuse compatible with both delta types
let the GIT native protocol use offsets to delta base when possible
zap a debug remnant
allow delta data reuse even if base object is a preferred base
index-pack: compare only the first 20-bytes of the key.
reduce delta head inflated size
add the capability for index-pack to read from a stream
enable index-pack streaming capability
make index-pack able to complete thin packs.
add progress status to index-pack
mimic unpack-objects when --stdin is used with index-pack
enhance clone and fetch -k experience
index-pack: minor fixes to comment and function name
missing small substitution
pack-objects doesn't create random pack names
make git-push a bit more verbose
Allow pack header preprocessing before unpack-objects/index-pack.
git-fetch can use both --thin and --keep with fetch-pack now
improve fetch-pack's handling of kept packs
have index-pack create .keep file more carefully
remove .keep pack lock files when done with refs update
git-pack-objects progress flag documentation and cleanup
OGAWA Hirofumi:
gitk: Fix nextfile() and add prevfile()
Petr Baudis:
Fix broken sha1 locking
Fix buggy ref recording
gitweb: Document features better
gitweb: Fix search form when PATH_INFO is enabled
bisect reset: Leave the tree in usable state if git-checkout failed
gitweb: Fix setting $/ in parse_commit()
gitweb: Restore object-named links in item lists
gitweb: Make search type a popup menu
gitweb: Do not automatically append " git" to custom site name
gitweb: Show project's README.html if available
xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
gitweb: Support for 'forks'
gitweb: Fix up bogus $stylesheet declarations
Nicer error messages in case saving an object to db goes wrong
Rene Scharfe:
git-archive --format=zip: use default version ID
git-archive --format=zip: add symlink support
git-merge: show usage if run without arguments
Built-in cherry
Make git-cherry handle root trees
git-cherry: document limit and add diagram
Robert Shearman:
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
git-rebase: Add a -v option to show a diffstat of the changes upstream at the start of a rebase.
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
Robin Rosenberg:
Mention that pull can work locally in the synopsis
Swap the porcelain and plumbing commands in the git man page
Rework cvsexportcommit to handle binary files for all cases.
Ryan Anderson:
Remove git-annotate.perl and create a builtin-alias for git-blame
Santi Béjar:
fetch: Misc output cleanup
merge and resolve: Output short hashes and .. in "Updating ..."
Documentation for the [remote] config
Sasha Khapyorsky:
git-svnimport.perl: copying directory from original SVN place
git-svnimport: support for partial imports
Sean Estabrooks:
Add --global option to git-repo-config.
Sergey Vlasov:
git-send-email: Document support for local sendmail instead of SMTP server
git-send-email: Read the default SMTP server from the GIT config file
Shawn Pearce:
Added completion support for git-branch.exe.
Added bash completion support for git-reset.
Use ULONG_MAX rather than implicit cast of -1.
Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
Remove unsupported C99 style struct initializers in git-archive.
Added missing completions for show-branch and merge-base.
Only load .exe suffix'd completions on Cygwin.
Bash completion support for remotes in .git/config.
Take --git-dir into consideration during bash completion.
Support bash completion on symmetric difference operator.
Remove more sed invocations from within bash completion.
Use column indexes in git-cvsserver where necessary.
Allow short pack names to git-pack-objects --unpacked=.
Only repack active packs by skipping over kept packs.
Teach git-index-pack how to keep a pack file.
Remove unused variable in receive-pack.
Move deny_non_fast_forwards handling completely into receive-pack.
Teach receive-pack how to keep pack files based on object count.
Tero Roponen:
remove an unneeded test
Tuncer Ayaz:
git-fetch.sh printed protocol fix
^ permalink raw reply
* Re: Missing features in git
From: Karl Hasselström @ 2006-11-15 7:35 UTC (permalink / raw)
To: linux; +Cc: git, torvalds
In-Reply-To: <20061114213800.28716.qmail@science.horizon.com>
On 2006-11-14 16:38:00 -0500, linux@horizon.com wrote:
> It also removes a paragraph of excuses from some "using git" docs
> I'm writing. It's a lot easier to explain why you can't commit if
> you're not on a branch than to explain why you can't not be on a
> branch.
This is precisely why writing documentation is such a good idea: It is
in many cases easier to fix the warts than finding a pedagogical way
to explain them. :-)
(Well, then there's the secondary benefit that users can learn from
the docs ...)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 6:30 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061115061833.GA6294@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Or even better, have "gh init".
>
> Why gh? Is Git just Mercurial backwards? :)
>
> I'm all in favor of this discussion, and in particular of just
> breaking the entire UI in 2.0 by using a new frontend command.
> I'm just not sure that "Mercurial backwards" describes Git well.
I do not have any obsession to any name as long as it is
different from "git" to avoid confusion coming from older
documents that would be found by googling. gh was just
shorthand for "git for humans" (and easy to type with index
fingers). I think I listed a few other possibilities in my
previous message.
^ permalink raw reply
* Re: [PATCH] Make cvsexportcommit work with filenames with spaces and non-ascii characters.
From: Junio C Hamano @ 2006-11-15 6:27 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <7v8xidqm1e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> But all of the above shows deficiency in the current set of
> tools -- they are not helping Porcelain writers enough. I think
> we should enhance 'apply --numstat' to let it show binary diffs
> differently:
>
> git diff-tree -p $parent $commit >.tmpfile
> git apply --numstat -z <.tmpfile
>
> would currently say "0 0" for binary files (the primary benefit
> of using "--numstat -z" here is that it would give Perl scripts
> pathnames parsable without C dequoting). We should somehow have
> a way to show it differently from text files without any
> added/deleted lines (e.g. only the mode change), and that would
> make the life of Porcelain writers who needs to write something
> like the above code much more pleasant. Perhaps show "- -"
> instead of "0 0", since there is no notion of lines in "binary
> files differ" case?
That is, something like this...
-- >8 --
[PATCH] apply --numstat: mark binary diffstat with - -, not 0 0
We do not even know number of lines so showing it as 0 0 is
lying. This would also help Porcelains like cvsexportcommit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-apply.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index aad5526..b80ad2c 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2116,7 +2116,11 @@ static void numstat_patch_list(struct pa
for ( ; patch; patch = patch->next) {
const char *name;
name = patch->new_name ? patch->new_name : patch->old_name;
- printf("%d\t%d\t", patch->lines_added, patch->lines_deleted);
+ if (patch->is_binary)
+ printf("-\t-\t");
+ else
+ printf("%d\t%d\t",
+ patch->lines_added, patch->lines_deleted);
if (line_termination && quote_c_style(name, NULL, NULL, 0))
quote_c_style(name, NULL, stdout, 0);
else
--
1.4.4.rc2.g2a54
^ permalink raw reply related
* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-15 6:26 UTC (permalink / raw)
To: linux; +Cc: git, junkio
In-Reply-To: <20061115062101.22280.qmail@science.horizon.com>
linux@horizon.com wrote:
> >> 1) make "git init" an alias for "git init-db".
>
> > Or even better, have "gh init".
>
> If you're going to be inspired by hg, pick a cleverer name. :-)
>
> If you want to add a thin attractive layer, silver-plate the thing and
> call it "ag". Since it contains the letter g as well, I'm sure that
> someone can come up with a good backronym for it.
Is "more Attractive Git" not good enough?
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: linux @ 2006-11-15 6:21 UTC (permalink / raw)
To: git, junkio; +Cc: linux
>> 1) make "git init" an alias for "git init-db".
> Or even better, have "gh init".
If you're going to be inspired by hg, pick a cleverer name. :-)
If you want to add a thin attractive layer, silver-plate the thing and
call it "ag". Since it contains the letter g as well, I'm sure that
someone can come up with a good backronym for it.
Latin element names:
Ag - Argentum
Au - Aureum
Cu - Cuprum
Fe - Ferrum
Hg - Hydrargyrum
K - Kalium
Na - Natrium
Pb - Plumbum
Sb - Stibium
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-15 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Andy Whitcroft, Carl Worth
In-Reply-To: <7vu011qnl6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Or even better, have "gh init".
Why gh? Is Git just Mercurial backwards? :)
I'm all in favor of this discussion, and in particular of just
breaking the entire UI in 2.0 by using a new frontend command.
I'm just not sure that "Mercurial backwards" describes Git well.
--
^ permalink raw reply
* Re: [PATCH] Make cvsexportcommit work with filenames with spaces and non-ascii characters.
From: Junio C Hamano @ 2006-11-15 6:08 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20061115005530.26560.18222.stgit@lathund.dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> From: Robin Rosenberg <robin.rosenberg@dewire.com>
>
> This patch uses git-apply to do the patching which simplifies the code a lot.
>
> Removed the test for checking for matching binary files when deleting them
> since git-apply happily deletes the file. This is matter of taste since we
> allow some fuzz for text patches also.
>
> Error handling was cleaned up, but not much testd (it did not work before).
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Thanks. Allow me to put this in freezer for a few days while
releasing v1.4.4.
Some comments below.
> @@ -116,12 +115,18 @@ if ($opt_a) {
> close MSG;
>
> my (@afiles, @dfiles, @mfiles, @dirs);
> -my @files = safe_pipe_capture('git-diff-tree', '-r', $parent, $commit);
> -#print @files;
> +my $files = safe_pipe_capture_blob('git-diff-tree', '-z', '-r', $parent, $commit);
> $? && die "Error in git-diff-tree";
> +while ($files =~ m/(.*?\000.*?\000)/g) {
> + my $f=$1;
> + $f =~ m/^(\S+) (\S+) (\S+) (\S+) (\S+)\000(.*)\000/;
> + my @fields = ();
> + $fields[++$#fields] = $1;
> + $fields[++$#fields] = $2;
> + $fields[++$#fields] = $3;
> + $fields[++$#fields] = $4;
> + $fields[++$#fields] = $5;
> + $fields[++$#fields] = $6;
my @fields = ($f =~ m/^.../);
> my (@binfiles, @abfiles, @dbfiles, @bfiles, @mbfiles);
> @binfiles = grep m/^Binary files/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
> map { chomp } @binfiles;
> @abfiles = grep s/^Binary files \/dev\/null and b\/(.*) differ$/$1/, @binfiles;
> @dbfiles = grep s/^Binary files a\/(.*) and \/dev\/null differ$/$1/, @binfiles;
> @mbfiles = grep s/^Binary files a\/(.*) and b\/(.*) differ$/$1/, @binfiles;
> +push @abfiles, grep s/^Binary files \/dev\/null and "b\/(.*)" differ$/$1/, @binfiles;
> +push @dbfiles, grep s/^Binary files "a\/(.*)" and \/dev\/null differ$/$1/, @binfiles;
> +push @mbfiles, grep s/^Binary files "a\/(.*)" and \"b\/(.*)\" differ$/$1/, @binfiles;
> +map { s/\\([\d]{3})/sprintf('%c',oct $1)/eg; } @abfiles;
> +map { s/\\([\d]{3})/sprintf('%c',oct $1)/eg; } @dbfiles;
> +map { s/\\([\d]{3})/sprintf('%c',oct $1)/eg; } @mbfiles;
> +
Logically these map {} should be done only on the c-quoted
names, but it is Ok because the names that have backslash with
octal are quoted. However, what's inside the map is not correct
c dequoting (see how Jakub does it in gitweb -- you need to
worry about \\, \" and such).
I think it is perhaps safer to parse "diff --git" and remember
the filenames of the "current patch" and then notice only
/^Binary files / part of the message.
But all of the above shows deficiency in the current set of
tools -- they are not helping Porcelain writers enough. I think
we should enhance 'apply --numstat' to let it show binary diffs
differently:
git diff-tree -p $parent $commit >.tmpfile
git apply --numstat -z <.tmpfile
would currently say "0 0" for binary files (the primary benefit
of using "--numstat -z" here is that it would give Perl scripts
pathnames parsable without C dequoting). We should somehow have
a way to show it differently from text files without any
added/deleted lines (e.g. only the mode change), and that would
make the life of Porcelain writers who needs to write something
like the above code much more pleasant. Perhaps show "- -"
instead of "0 0", since there is no notion of lines in "binary
files differ" case?
> - `cvs add $d`;
> - if ($?) {
> - $dirty = 1;
> + print "Adding directory $d";
> + if (system('cvs','add',$d)) {
> + $dirtypatch = 1;
Good.
> ## apply non-binary changes
> my $fuzz = $opt_p ? 0 : 2;
>
> -print "Patching non-binary files\n";
> +print "Patching\n";
Leftover comment that does not apply anymore.
> if (scalar(@afiles)+scalar(@dfiles)+scalar(@mfiles) != scalar(@bfiles)) {
> + `git-diff-tree --binary -z -p $parent -p $commit >.cvsexportcommit.diff`;
Haven't you run this diff before to grep for "Binary files..."
Maybe doing a temporary file upfront once and using it would
make sense.
Also why multiple -p? I do not think -z is wanted here, as -z
affects only output side of git apply and not input side (see
the above comment on --numstat -z).
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Junio C Hamano @ 2006-11-15 5:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Andy Whitcroft, Carl Worth
In-Reply-To: <Pine.LNX.4.64.0611142048350.2591@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> What is the point of hiding tracking branches? Why just not making them
> easier to use instead? There are currently so many ways to specify
> remote branches that even I get confused.
Ok, I think in essence we are saying the same thing except I
went overboard by suggsting to extend sha1_name to also look at
.git/remotes/$name which is not necessary, because we already
have the .git/refs/remotes/%s/HEAD magic there. Consider the
suggestion of "upstream#next" syntax retracted, please.
> 1) make "git init" an alias for "git init-db".
Or even better, have "gh init".
> 2) "pull" and "push" should be symmetrical operations
I think that makes a lot of sense to have "gh pull" and "gh
push" as symmetric operations, and make "gh merge" do the
fast-forward and 3-way merge magic done in the current "git
pull". These three words would have a lot saner meaning.
> 3) remote branch handling should become more straight forward.
>
> OK! Now that we've solved the pull issue and that everybody agrees with
> me (how can't you all agree with me anyway) let's have a look at remote
> branches.
I would probably prefer making the default namespace under
.git/refs/remotes/remote-name for the tracking branches this
proposal creates, but other than that I agree with the general
direction this proposal is taking us, including branch groups.
We have .git/refs/remotes/%s/HEAD magic so I do not think we
even need to treat one branch repository any specially as you
suggsted.
The reason I am suggsting "gh" instead of "git" is primarily to
deal with stale documentation people would find googling. I can
easily see people get confused by reading "pull = fetch + merge"
from either mailing list archive or Git cheat sheet various
projects seem to have developed.
It does not mean we need to redo _all_ UI. I think most of the
archaeology commands have sane UI so during the transition
period (git 1.99) we can have "git log" and "gh log" which are
one and the same program, and perhaps git 2.0 can be shipped
with clear distinction between plumbing (i.e. git-update-index
and friends) and porcelain (e.g. "gh pull" that only fetches but
with the user friendliness you outlined here), with backward
compatibility wart to help old timers (e.g. "git pull" that
still does "git fetch" followed by "git merge").
^ 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