* Re: How to commit removed file?
From: Juergen Ruehle @ 2007-01-02 21:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael S. Tsirkin, git
In-Reply-To: <Pine.LNX.4.63.0701022211100.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin writes:
> On Tue, 2 Jan 2007, Michael S. Tsirkin wrote:
>
> > > I'd like to remove a file and commit the removal while
> > > leaving out other changes in repository/index.
> > >
> > > $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
> > > rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
> > >
> > > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> > > error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
> > > any file(s) known to git.
> > > Did you forget to 'git add'?
> > >
> > > A similiar thing works with "git add".
> >
> > Any ideas? Can this be done with git?
>
> Did you actually try the "--" thing I suggested in
> http://article.gmane.org/gmane.comp.version-control.git/35699/?
>
> Besides, I just tested with current "next":
>
> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
> 1 files changed, 0 insertions(+), 22 deletions(-)
> delete mode 100644 a234
But (at least in next from yesterday or something -- having an old
modem here only:-) it doesn't work if you delete the file using
git-rm, because git-commit -o operates only on known files: one of the
first things in this code path is a
git-ls-files --error-unmatch -- $@
This seems wrong because -o is supposed to bypass the index. It
should probably be doing ls-tree --name-only HEAD -- $@ instead, but
ls-tree doesn't have the --error-match functionality.
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.
From: Johannes Schindelin @ 2007-01-02 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, Shawn O. Pearce, git
In-Reply-To: <7vr6ufeuvf.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 31 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> While we're talking about potentially deprecating GIT_DIR for users,
> >> out of curiosity, what valid workflows would cause users to want to
> >> use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY? Seems like they would
> >> cause more confusion and support problems than anything else.
> >
> > Easy, guys.
> >
> > It is a valid -- indeed, useful -- thing to be able to script nice
> > helpers. For example, in one project I track tar balls. So, I wrote a
> > script which will unpack the tar ball in a directory, build a new index
> > from it, and commit the corresponding tree on top of the tracking branch.
> > This setup relies _heavily_ on being able to redirect GIT_INDEX_FILE and
> > GIT_DIR.
>
> I do agree INDEX_FILE and OBJECT_DIRECTORY are handy things for
> the user to muck around. What I am not sure about is GIT_DIR,
> in the sense that I suspect it is not such a pain to do without
> for such a script.
Uhm. In the example I illustrated, I need to set GIT_DIR, because I want
to commit a new version into a branch of my current repository, but
without touching the working tree and the index.
Thus, I have to create a temporary directory, unpack the new
(upstream) version, set GIT_DIR _and_ GIT_INDEX_FILE, do a write-tree and
a commit-tree with some automatic message, and then update the ref. Yes, I
could separate the steps, but why make it harder than it needs be?
> > ... Now, if somebody starts git in a
> > bare repo, where "index" is present, it could die with a helpful message
> > like
> >
> > It seems that this is a bare git repository, but there is an index
> > file present, which contradicts that assumption. If the repository
> > is indeed bare, please remove the index file.
>
> That is probably worse.
>
> * there is no reason for non working-tree operations such as
> git-log to fail when you go to a bare repository (or for that
> matter .git in a repository with a working-tree). we should
> not have to error out nor remove the index we will not use.
>
> * if you did the above in response to a misguided 'git
> checkout' in a bare repository, the next error message the
> user will get will be 'huh? you are in a bare repository,
> bozo'.
>
> So I do not think the helpful message should even be necessary.
Yeah, I meant this message only to appear when you call a program which
needs a working directory. But I agree that this is probably stupid.
Ciao,
Dscho
^ permalink raw reply
* Re: How to commit removed file?
From: Junio C Hamano @ 2007-01-02 21:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Michael S. Tsirkin
In-Reply-To: <Pine.LNX.4.63.0701022211100.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 2 Jan 2007, Michael S. Tsirkin wrote:
>
>> > I'd like to remove a file and commit the removal while
>> > leaving out other changes in repository/index.
>> >
>> > $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
>> > rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
>> >
>> > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
>> > error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
>> > any file(s) known to git.
>> > Did you forget to 'git add'?
>> >
>> > A similiar thing works with "git add".
>>
>> Any ideas? Can this be done with git?
>
> Did you actually try the "--" thing I suggested in
> http://article.gmane.org/gmane.comp.version-control.git/35699/?
>
> Besides, I just tested with current "next":
>
> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
> 1 files changed, 0 insertions(+), 22 deletions(-)
> delete mode 100644 a234
The difference is Michael did "git rm" to explicitly tell git to
forget about that path, while you used the vanilla "/bin/rm".
Personally I never saw the point of having "git rm". Maybe we
should remove it to prevent this confusion from happening.
^ permalink raw reply
* Re: Possible regression in git-rev-list --header
From: Johannes Schindelin @ 2007-01-02 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
In-Reply-To: <7vodpja0u8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 31 Dec 2006, Junio C Hamano wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > On 12/31/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >>
> >> Further, if you rely on parsing being super-fast, why not just parse
> >> _only_ the header information that you actually need? The header still
> >> consists of
> >>
> >> - exactly one "tree",
> >> - an arbitrary amount of "parent" lines,
> >> - exactly one "author", and
> >> - exactly one "committer" line
> >>
> >> After that may come optional headers,
>
> They are more like 'other' headers.
I should have been more clear: optional for the committer.
> > If you intorduce the concept of an 'optional header part' you
> > logically and naturally _may_ also introduce the concept of disabling
> > the display of _that_ optional header, or better, to keep back
> > compatibility...
>
> While I am somewhat sympathetic, and am willing to apologize for
> trying to advance the i18n support without enough advance
> warning, I think you already know what you are saying does not
> make much sense in the larger picture and as the longer term
> solution.
Besides, when you say
> The problem with your proposed algorithm is that you don't have _one_
> commit but a sequence of commits to parse, so when you have parsed until
> the committer line you must need to know where the next commit starts,
> IOW you have to find the next '\0', that's what I was trying to expose
> in my previous e-mail postscriptum.
I don't get _at all_ what could be a problem _with_ the encoding header
that is no problem _without_ it. I assume you want to tell me something
more than that you do not want to change your code? If so, I missed it.
> * When the output encoding conversion is done successfully, the
> current tip of master drops "encoding" header from the
> output, [...]
Earlier, I said that I do not feel strongly about that issue.
But now I do.
If you drop the "encoding" header from the commit buffer, just because you
reencoded it to whatever encoding happens to be the one the caller just
asked for, you are _not_ interpreting the data, but _changing_ it.
That is not what git is about, IMHO. It would be a completely different
thing if the caller had a way to ask for _specific_ headers, and asks to
be left alone with all the other cruft. But the caller does not even have
the chance to say that, let alone ask specifically _for_ it.
The encoding header bears information, just like the tree header or the
committer header. I find it highly irritating that I am shielded from it.
The encoding header has _nothing_ to do with the encoding that the output
is being encoded with, but _all_ with how the commit message was encoded
_by the committer_.
> The reason we did the latter, by the way, does not have anything
> to do with helping broken parsers. We drop the header after
> re-coding the log message into an encoding specified by the user
> (which is presumably different from what the commit was
> originally recorded in) because the encoding recorded on
> "encoding" header would not match the re-coded log message
> anymore.
By the same reasoning, you'd have to rewrite the committer line to reflect
the current GIT_COMMITTER_IDENT, or hide it. If you want to convince me,
you have to try harder.
And Marco has to fix the header parsing anyway.
So, please, Junio, can you rethink that decision?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments
From: Brian Gernhardt @ 2007-01-02 21:26 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, Steve Frécinaux, git
In-Reply-To: <20070102211339.GF17898@hades.madism.org>
> The reason is simple, I often use git commit as :wq in my editor,
> and
> sometimes think that in a A--B--C--D and in fact, I'd prefer to have:
>
> {A,C}--B--D. how is it possible to do that in a not too cumbersome
> way? because that would make sens to work in some scratch branch, and
> then reorganize patches in a saner better way in the master branch.
>
> But I fail to see how to achieve that without using cumbersome
> export-to-patch then git apply patch and edit logs which is painful
> and
> not really using git.
The command you seem to be looking for is git-cherry-pick. To
combine the two commits, I'd do something like:
$ git cherry-pick A
$ git cherry-pick C
$ git reset HEAD~2
$ git add <files>
$ git commit
And then you could rebase the work branch on top of the new master,
which should catch that A and C were already committed with minimal
effort. Of course there may be a cleaner way to do it, but this is
what I do.
~~ Brian Gernhardt
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts
From: Johannes Schindelin @ 2007-01-02 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vk605t9qz.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 2 Jan 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > That is certainly a possibility! But how would you specify it? If you
> > do it as a command line option, you'd have to add it to git-merge,
> > git-pull, git-merge-recursive and git-merge-file. Ugly.
>
> Another thing to worry about is that this would make things
> "works most of the time but when it fails it fails silently"
> which would lead to very hard to detect problem in the project
> managed by git. I'd be very hesitant about this for this reason
> alone.
Right. That was what I was alluding to with my comment "what if you prefer
the deletion over the addition?"
It _seems_ clever at first sight, but it isn't.
Ciao,
Dscho
^ permalink raw reply
* [RFC] Re: git-svn: make git-svn commit-diff able to work without explicit arguments
From: Pierre Habouzit @ 2007-01-02 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steve Frécinaux, git
In-Reply-To: <7vr6udtbmv.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]
On Tue, Jan 02, 2007 at 12:30:16PM -0800, Junio C Hamano wrote:
> Steve Frécinaux <nudrema@gmail.com> writes:
>
> > When using git-svn to access a SVN repo, the commit policy may
> > vary. While git makes you commit small patches often, svn users tend
> > to prefer bigger patches that implement a functionnality at once.
> >
> > So at the end you have a SVN commit which corresponds to several git ones.
>
> I personally think this is solving a wrong problem. Commit
> granularity is a property of the project, the way in which
> people involved in the project prefer working. It is not about
> "svn users" vs "git users", and it shouldn't be, especially if
> the end result is still a single project.
>
> Is git "making you commit small patches often"? I honestly hope
> we are not forcing you to do so, although we took pains to make
> it easier because it tends to be easier to look at the history
> later when commit boundaries match the logical steps of
> evolution.
>
> So my suggestion would be to educate people who tend to make too
> large commits better separate their commits, and at the same
> time coallesce the commits you create on the git side into a
> presentable size, if you acquired a bad habit of making too
> small commits, so that everybody follows the same commit
> granularity guideline set by the project.
Though an operation that I'd often like to do is to merge two (or
more) patches as one, and reedit its entry, preferably as a merge of the
two (or more) old logs.
The reason is simple, I often use git commit as :wq in my editor, and
sometimes think that in a A--B--C--D and in fact, I'd prefer to have:
{A,C}--B--D. how is it possible to do that in a not too cumbersome
way? because that would make sens to work in some scratch branch, and
then reorganize patches in a saner better way in the master branch.
But I fail to see how to achieve that without using cumbersome
export-to-patch then git apply patch and edit logs which is painful and
not really using git.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: How to commit removed file?
From: Johannes Schindelin @ 2007-01-02 21:12 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20070102201041.GB10451@mellanox.co.il>
Hi,
On Tue, 2 Jan 2007, Michael S. Tsirkin wrote:
> > I'd like to remove a file and commit the removal while
> > leaving out other changes in repository/index.
> >
> > $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
> > rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
> >
> > $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> > error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
> > any file(s) known to git.
> > Did you forget to 'git add'?
> >
> > A similiar thing works with "git add".
>
> Any ideas? Can this be done with git?
Did you actually try the "--" thing I suggested in
http://article.gmane.org/gmane.comp.version-control.git/35699/?
Besides, I just tested with current "next":
$ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
Created commit 89a5bb5ac16fb8be9b6e061284e191cafb3e4da2
1 files changed, 0 insertions(+), 22 deletions(-)
delete mode 100644 a234
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts
From: Junio C Hamano @ 2007-01-02 21:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.63.0701022144290.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> That is certainly a possibility! But how would you specify it? If you
> do it as a command line option, you'd have to add it to git-merge,
> git-pull, git-merge-recursive and git-merge-file. Ugly.
Another thing to worry about is that this would make things
"works most of the time but when it fails it fails silently"
which would lead to very hard to detect problem in the project
managed by git. I'd be very hesitant about this for this reason
alone.
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts
From: Johannes Schindelin @ 2007-01-02 20:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200701021418.48624.jnareb@gmail.com>
Hi,
On Tue, 2 Jan 2007, Jakub Narebski wrote:
> On Sun, 31 Dec 2006, Johannes Schindelin wrote:
>
> > On Sat, 30 Dec 2006, Jakub Narebski wrote:
> >
> >> Johannes Schindelin wrote:
> >>
> >>> Of course, you can hit mismerges like the illustrated one _without_
> >>> being marked as conflict (e.g. if the chunk of identical code is _not_
> >>> added, but only the increments), but we should at least avoid them
> >>> where possible.
> >>
> >> Perhaps you could make it even more conservating merge conflicts option
> >> (to tighten merge conflicts even more) to xdl_merge, but not used by
> >> default because as it removes accidental conflicts it increases
> >> mismerges (falsely not conflicted).
> >
> > There is no way to do this sanely. If you want to catch these mismerges,
> > you have to mark _all_ modifications as conflicting.
>
> Currently you have:
> - a level value of 0 means that all overlapping changes are treated
> as conflicts,
> - a value of 1 means that if the overlapping changes are identical,
> it is not treated as a conflict.
> - If you set level to 2, overlapping changes will be analyzed, so that
> almost identical changes will not result in huge conflicts. Rather,
> only the conflicting lines will be shown inside conflict markers.
>
> I was thinking about:
> - If you set level to 3, if one part after overlapping changes analysis
> in level 2 has empty conflict region, resolve this conflict as second
> side. WARNING: this reduces number of merge conflicts, but might give
> mismerges!
That is certainly a possibility! But how would you specify it? If you
do it as a command line option, you'd have to add it to git-merge,
git-pull, git-merge-recursive and git-merge-file. Ugly.
You could do it as a config variable, but git-merge-file operates without
a git repository. And you'd want it to be overrideable anyway.
Environment variable? Too unfriendly to users, because it is not really a
proper UI.
It is certainly easy enough to teach the code (but might introduce
unwanted side effects, when the _deletion_, not the _addition_ was what
you wanted):
xdiff/xdiff.h | 1 +
xdiff/xmerge.c | 21 ++++++++++++++++++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index fa409d5..bdf12e3 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -52,6 +52,7 @@ extern "C" {
#define XDL_MERGE_MINIMAL 0
#define XDL_MERGE_EAGER 1
#define XDL_MERGE_ZEALOUS 2
+#define XDL_MERGE_OVERZEALOUS 3
typedef struct s_mmfile {
char *ptr;
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index b83b334..e7b740f 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -180,7 +180,7 @@ static int xdl_fill_merge_buffer(xdfenv_t *xe1, const char *name1,
* lines. Try hard to show only these few lines as conflicting.
*/
static int xdl_refine_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
- xpparam_t const *xpp)
+ int level, xpparam_t const *xpp)
{
for (; m; m = m->next) {
mmfile_t t1, t2;
@@ -225,6 +225,12 @@ static int xdl_refine_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
m->chg1 = xscr->chg1;
m->i2 = xscr->i2 + i2;
m->chg2 = xscr->chg2;
+ if (level >= XDL_MERGE_OVERZEALOUS) {
+ if (!m->chg1)
+ m->mode = 2;
+ else if (!m->chg2)
+ m->mode = 1;
+ }
while (xscr->next) {
xdmerge_t *m2 = xdl_malloc(sizeof(xdmerge_t));
if (!m2) {
@@ -241,6 +247,12 @@ static int xdl_refine_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
m->chg1 = xscr->chg1;
m->i2 = xscr->i2 + i2;
m->chg2 = xscr->chg2;
+ if (level >= XDL_MERGE_OVERZEALOUS) {
+ if (!m->chg1)
+ m->mode = 2;
+ else if (!m->chg2)
+ m->mode = 1;
+ }
}
xdl_free_env(&xe);
xdl_free_script(x);
@@ -252,6 +264,7 @@ static int xdl_refine_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
* level == 0: mark all overlapping changes as conflict
* level == 1: mark overlapping changes as conflict only if not identical
* level == 2: analyze non-identical changes for minimal conflict set
+ * level == 3: if one side in the analysis is empty, assume no conflict
*
* returns < 0 on error, == 0 for no conflicts, else number of conflicts
*/
@@ -290,7 +303,7 @@ static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1, const char *name1,
xscr2 = xscr2->next;
continue;
}
- if (level < 1 || xscr1->i1 != xscr2->i1 ||
+ if (level < XDL_MERGE_EAGER || xscr1->i1 != xscr2->i1 ||
xscr1->chg1 != xscr2->chg1 ||
xscr1->chg2 != xscr2->chg2 ||
xdl_merge_cmp_lines(xe1, xscr1->i2,
@@ -355,7 +368,9 @@ static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1, const char *name1,
if (!changes)
changes = c;
/* refine conflicts */
- if (level > 1 && xdl_refine_conflicts(xe1, xe2, changes, xpp) < 0) {
+ if (level >= XDL_MERGE_ZEALOUS &&
+ xdl_refine_conflicts(xe1, xe2, changes,
+ xpp, level) < 0) {
xdl_cleanup_merge(changes);
return -1;
}
^ permalink raw reply related
* Re: [RFC] git-svn: make git-svn commit-diff able to work without explicit arguments
From: Junio C Hamano @ 2007-01-02 20:30 UTC (permalink / raw)
To: Steve Frécinaux; +Cc: git
In-Reply-To: <459AA31E.5070705@gmail.com>
Steve Frécinaux <nudrema@gmail.com> writes:
> When using git-svn to access a SVN repo, the commit policy may
> vary. While git makes you commit small patches often, svn users tend
> to prefer bigger patches that implement a functionnality at once.
>
> So at the end you have a SVN commit which corresponds to several git ones.
I personally think this is solving a wrong problem. Commit
granularity is a property of the project, the way in which
people involved in the project prefer working. It is not about
"svn users" vs "git users", and it shouldn't be, especially if
the end result is still a single project.
Is git "making you commit small patches often"? I honestly hope
we are not forcing you to do so, although we took pains to make
it easier because it tends to be easier to look at the history
later when commit boundaries match the logical steps of
evolution.
So my suggestion would be to educate people who tend to make too
large commits better separate their commits, and at the same
time coallesce the commits you create on the git side into a
presentable size, if you acquired a bad habit of making too
small commits, so that everybody follows the same commit
granularity guideline set by the project.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-01-02 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt4647g0.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 1 Jan 2007, Junio C Hamano wrote:
> * jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
> + git-merge: preserve and merge local changes when doing fast
> forward
>
> Johannes's suggestion to record a tree object instead of LOCAL_DIFF is
> roger but not wilco yet --- I haven't thought through the issue to see
> an improvement in the suggestion. We will be clobbering both index and
> the working tree, and I think "diff --binary HEAD" and "write-tree"
> record the equivalent amount of information given a HEAD for recovery.
For recovery, yes. The difference comes in
- that you can use the familiar git operations to recover (git read-tree
PRE_MERGE_TREE), and
- that you can do other git operations on the tree, but not on the diff.
Hth,
Dscho
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Jakub Narebski @ 2007-01-02 20:30 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wmdure6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Obviously, the local names should matter more when you are doing
> local operations. So if you are using mergeLocal to give a
> shorthand to "git merge" that does not explicitly say what to
> merge, the above discussion does not apply. But if that is the
> case, mergeLocal should also not affect the selection of
> branches to be merged when "git pull" happens from a remote
> either.
You can always use remote = ".", and then remote and local branches
are the same...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to commit removed file?
From: Michael S. Tsirkin @ 2007-01-02 20:10 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20061231102444.GD26552@mellanox.co.il>
> I'd like to remove a file and commit the removal while
> leaving out other changes in repository/index.
>
> $git rm kernel_patches/fixes/ib_verbs_warning_fix.patch
> rm 'kernel_patches/fixes/ib_verbs_warning_fix.patch'
>
> $ git commit kernel_patches/fixes/ib_verbs_warning_fix.patch
> error: pathspec 'kernel_patches/fixes/ib_verbs_warning_fix.patch' did not match
> any file(s) known to git.
> Did you forget to 'git add'?
>
> A similiar thing works with "git add".
Any ideas? Can this be done with git?
--
MST
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Junio C Hamano @ 2007-01-02 20:04 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, git
In-Reply-To: <20070102173410.GA25325@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jan 02, 2007 at 09:32:30AM -0800, Junio C Hamano wrote:
>
>> If we are to worry about, and I think we might have to, I think
>> not worrying about mergelocal and not accepting the name of
>> local tracking branch is the only sensible thing to do.
>
> Sorry, I don't see the problem with mergelocal. Can you elaborate?
I might have misread what you meant by mergeLocal, and you might
be trying to introduce a default for "git merge" so that without
anything on the command line "git merge" would merge something
locally available depending on which branch you are on.
But I did not think of that, and thought you were saying "look
at branch.*.mergelocal (if exists) in the same place we look at
branch.*.merge in the current code, and just like the latter is
used to match up with the remote refname we just fetched, use
the former to match the local tracking branches, to decide what
to merge". And if that is what you meant by mergelocal, I do
not see much advantage in that approach -- that is what I meant
in the response. The remote name is available whether you use
tracking branches locally or not, so using that to specify the
merge operation that happens after a 'pull' is more consistent,
less confusing, and matches the long-hand "git pull $URL
remote-branch" a lot better than having another configuration
that can be used only half the time.
Some people repeatedly argued that remote branch names do not
matter. I think they are wrong and are missing the point of
distributedness of git. You are fetching from there, so you
need to know the name the other end gives them in the first
place. But much more importantly, the fact you are fetching
from there means some other people could also be fetching from
the same place. Now how would you discuss what that common
repository recently placed on that branch? You would not use
the local tracking branch name which _is_ meaningless to the
other person. You use the remote name.
For example, I have a separate repository (that happens to be
checked out in Meta/ subdirectory of my main working area, so
its control files are in Meta/.git repository) to keep things
that I push to my 'todo' branch. After I push the updates to
'todo' out to kernel.org from that repository, I usually fetch
from kernel.org into that repository, so that I can later see up
to which one I have already pushed out. I am old fashioned and
still use remotes and non 'separate-remote' layout for this:
URL: kernel.org:/pub/scm/git/git.git
Push: refs/heads/master:refs/heads/todo
Pull: refs/heads/todo:refs/heads/ko
As you can see from the above, my 'ko' is the local tracking
branch, and 'master' in that repository is what is known as
'todo' to the public. But when I talk about what I have in that
branch, I would never say 'master' nor 'ko' -- people would not
care how I call that branch locally in my private repository.
What's private is private and does not matter to others.
Instead I would say something like "my 'todo' branch has drafts
for v1.5.0 release notes these days".
What does this all mean? It means that remote branch names
matter more when you are talking about external communication.
And "git pull" (more so for "git fetch") is all about external
communication.
Obviously, the local names should matter more when you are doing
local operations. So if you are using mergeLocal to give a
shorthand to "git merge" that does not explicitly say what to
merge, the above discussion does not apply. But if that is the
case, mergeLocal should also not affect the selection of
branches to be merged when "git pull" happens from a remote
either.
^ permalink raw reply
* Re: www.kernel.org/git
From: Robert Fitzsimons @ 2007-01-02 19:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Aneesh Kumar K.V, git, warthog19
In-Reply-To: <46a038f90701012325w3738ddd7l841f017453272aa3@mail.gmail.com>
> Which URLs are failing for you?
The url is correct but it should only be displayed and not be a
clickable link.
Also can I suggest that the link be moved to the summary page, it really
messes up the look of the project_list action page.
> This does look broken... I'll see if I can find out more.
It's broken because the search action page still prints it's output
instead of concatenating the output to a string and returning the string
in gitweb/gitweb/search.pm.
Robert
^ permalink raw reply
* Re: [PATCH] Detached HEAD (experimental)
From: Edgar Toernig @ 2007-01-02 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vac11yirf.fsf@assigned-by-dhcp.cox.net>
[Note: casual git-user speaking]
Junio C Hamano wrote:
>
> This allows "git checkout -d v1.4.3" to detach the HEAD from any
> branch but point directly at the named commit. After this, "git
> branch" starts reporting that you are not on any branch.
Nice. But why -d? Create more confusion? [1]
> You can go back the normal state by switching to an existing
> branch, say, "git checkout master" for example.
This is fine. Often you want to test a couple of tags, one
after another, so "git checkout v1", "git checkout v2", ...
should work.
> Another way to get out of this is "git checkout -b newbranch".
Wth should this do? I already noticed this line in your posting
from 29.Dec: [slightly edited]
$ git checkout v1.5.0
Checking out a tag -- you are not on any branch now...
$ <modify>
$ git commit -m 'fix' -a
You cannot commit without a current branch.
$ git checkout -b maint-1.5.0
$ git commit -m 'fix' -a
I assume it will create a new branch and modify HEAD so that
the current working dir/index gets committed into that branch.
(Basically "git branch main-1.5.0 &&
echo 'ref: refs/head/main-1.5.0' >.git/HEAD")
If that's the case, I was looking for that incantation for
a long time and couldn't find it. I'm using the git-branch
and echo as shown above to get that. The man-page isn't
very helpful for that special case of git-checkout.
Anyway, if I want to commit and git tells me that I can't
because I'm not on a branch, the _most unintuitive_ thing
would be calling 'git-checkout'. I want to checkin! No
way that I call checkout and risk losing all my changes.
What's wrong with a -b option to commit, similar to -b on
checkout?
$ git checkout v1.5.0
Checking out a tag -- you are not on any branch now...
$ <modify>
$ git commit -m 'fix' -a
You cannot commit without a current branch.
Give '-b <newbranch>' to commit into a new branch.
$ git commit -b maint-1.5.0 -m 'fix' -a
Another variant (the one I prefer): commit just updates HEAD and
git-branch can be used to give it a name (and switch to it!).
So these workflows would be possible:
Name after commit:
$ git checkout v1.5.0
Checking out a tag -- you are not on any branch now...
$ git branch
master
* (unnamed) c8ff51290518949225c832bae1e22b1bba6ab2cd
$ <modify>
$ git commit -m 'fix' -a
Warning: data committed into unnamed branch.
Give it a name now with "git branch <newname>"
$ git branch
master
* (unnamed) 13482f25863e5380cdd41065338e1709d469a605
$ git branch maint-1.5.0
$ git branch
master
* main-1.5.0
or name before commit:
$ git checkout v1.5.0
Checking out a tag -- you are not on any branch now...
$ <modify>
$ git branch
master
* (unnamed) c8ff51290518949225c832bae1e22b1bba6ab2cd
$ git branch maint-1.5.0
$ git branch
master
* maint-1.5.0
$ git commit -m 'fix' -a
Yes, 'git branch <newname>' would get a new semantic:
if no start-point is given the newname will become the
new current branch.
[Btw, I would even do that when we are on some branch. How
often did I do a checkout of a regular branch and only later
noticed, that I want to commit changes into a temp-branch:
$ git checkout master
$ <play around, fix compile issues, add debug stuff>
$ git branch debug
$ git branch
master
* debug
$ git commit -a -m "Add foo debugging code"
]
But that special case is IMHO (M = my, a casual user's) much
better than some weird checkout-incantations.
Ciao, ET.
[1] My pet-peeve:
$ git checkout foo
fatal: Entry 'bar' not uptodate. Cannot merge.
What the heck? Nobody asked for a merge!?!?! What
is it trying to do? Does it actually mean:
fatal: Working dir is dirty. Either give '-f'
to force the checkout and lose your changes, or
give '-m' to merge 'foo' and your changes.
? But then, why does an 'rm bar' fixes that? Now 'bar'
definitely isn't "uptodate".
^ permalink raw reply
* Re: [RFC/PATCH] fail pull/merge early in the middle of conflicted merge
From: Junio C Hamano @ 2007-01-02 19:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070101204354.GA26687@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> After a pull that results in a conflicted merge, a new user
>> often tries another "git pull" in desperation. When the index
>> is unmerged, merge backends correctly bail out without touching
>> either index nor the working tree, so this does not make the
>> wound any worse.
>
> I've seen this many times too. I don't understand why users cannot
> read output messages and realize the current command failed, but
> they don't. *sigh*
That is not user's fault. Tools should not make things worse
when run more than once after they failed, and we do not either,
so it is not a stupid behaviour on the user's part to do that.
We just need to make sure that it is more clear to the user that
pull after a conflicted pull is futile, which is what this patch
does.
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Junio C Hamano @ 2007-01-02 19:30 UTC (permalink / raw)
To: ltuikov; +Cc: git, J. Bruce Fields
In-Reply-To: <560316.34562.qm@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> Luben Tuikov <ltuikov@yahoo.com> writes:
>>
>> > Questions:
>> >
>> > What is the reasonining of defining branch.<name>.merge to point
>> > to the "remote's setup"?
>>
>> See list archives.
>>
>> Because you are not required to use remote tracking branches.
>
> Then why does it point to the _remote_ mapping? One shouldn't
Because [remote] is NOT about mapping. It asks the fetch
mechanism to fetch from that remote, so the primary thing you
should look at is .url, not RHS of colon on .fetch lines. Use
of tracking branches is strictly optional.
^ permalink raw reply
* [PATCH 4/4] Support --amend on initial commit in status output
From: Juergen Ruehle @ 2007-01-02 19:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jürgen Rühle
In-Reply-To: <1167765983316-git-send-email-j.ruehle@bmiag.de>
From: =?iso-8859-1?q?J=FCrgen_R=FChle?= <j-r@online.de>
We check the existence of the parent commit to determine whether the status is
requested for an initial commit. Since the parent commit depends on the
presence of the --amend switch do initial commit detection after command line
arguments have been handled.
Signed-off-by: Jürgen Rühle <j-r@online.de>
---
wt-status.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 302f7ee..166d0e3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -41,8 +41,6 @@ void wt_status_prepare(struct wt_status *s)
unsigned char sha1[20];
const char *head;
- s->is_initial = get_sha1("HEAD", sha1) ? 1 : 0;
-
head = resolve_ref("HEAD", sha1, 0, NULL);
s->branch = head ? xstrdup(head) : NULL;
@@ -287,6 +285,9 @@ static void wt_status_print_verbose(struct wt_status *s)
void wt_status_print(struct wt_status *s)
{
+ unsigned char sha1[20];
+ s->is_initial = get_sha1(s->reference, sha1) ? 1 : 0;
+
if (s->branch)
color_printf_ln(color(WT_STATUS_HEADER),
"# On branch %s", s->branch);
--
1.5.0.rc0.g31e2
^ permalink raw reply related
* [PATCH 3/4] Improve "nothing to commit" part of status output
From: Juergen Ruehle @ 2007-01-02 19:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jürgen Rühle
In-Reply-To: <1167765983316-git-send-email-j.ruehle@bmiag.de>
From: =?iso-8859-1?q?J=FCrgen_R=FChle?= <j-r@online.de>
Previously git-status in a clean working directory would advice the user to use
git add. This isn't very helpful when there is nothing to add in the working
directory, therefore note a clean working directory while displaying the other
sections and print the appropriate message for each case.
Signed-off-by: Jürgen Rühle <j-r@online.de>
---
wt-status.c | 20 +++++++++++++++-----
wt-status.h | 1 +
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 98ca135..302f7ee 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -51,6 +51,8 @@ void wt_status_prepare(struct wt_status *s)
s->verbose = 0;
s->commitable = 0;
s->untracked = 0;
+
+ s->workdir_clean = 1;
}
static void wt_status_print_cached_header(const char *reference)
@@ -173,9 +175,12 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
struct diff_options *options,
void *data)
{
+ struct wt_status *s = data;
int i;
- if (q->nr)
+ if (q->nr) {
+ s->workdir_clean = 0;
wt_status_print_header("Changed but not added", use_add_msg);
+ }
for (i = 0; i < q->nr; i++)
wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
if (q->nr)
@@ -225,7 +230,7 @@ static void wt_status_print_changed(struct wt_status *s)
run_diff_files(&rev, 0);
}
-static void wt_status_print_untracked(const struct wt_status *s)
+static void wt_status_print_untracked(struct wt_status *s)
{
struct dir_struct dir;
const char *x;
@@ -260,6 +265,7 @@ static void wt_status_print_untracked(const struct wt_status *s)
continue;
}
if (!shown_header) {
+ s->workdir_clean = 0;
wt_status_print_header("Untracked files", use_add_msg);
shown_header = 1;
}
@@ -302,9 +308,13 @@ void wt_status_print(struct wt_status *s)
if (s->verbose && !s->is_initial)
wt_status_print_verbose(s);
if (!s->commitable)
- printf("%s (%s)\n",
- s->amend ? "# No changes" : "nothing to commit",
- use_add_msg);
+ if (s->amend)
+ printf("# No changes\n");
+ else if (s->workdir_clean)
+ printf(s->is_initial ? "nothing to commit\n"
+ : "nothing to commit (working directory matches HEAD)\n");
+ else
+ printf("no changes added to commit (use \"git add\" and/or \"git commit [-a|-i|-o]\")\n");
}
int git_status_config(const char *k, const char *v)
diff --git a/wt-status.h b/wt-status.h
index 0a5a5b7..892a86c 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -16,6 +16,7 @@ struct wt_status {
int verbose;
int amend;
int untracked;
+ int workdir_clean;
};
int git_status_config(const char *var, const char *value);
--
1.5.0.rc0.g31e2
^ permalink raw reply related
* [PATCH 2/4] Improve cached content header of status output
From: Juergen Ruehle @ 2007-01-02 19:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jürgen Rühle
In-Reply-To: <1167765983316-git-send-email-j.ruehle@bmiag.de>
From: =?iso-8859-1?q?J=FCrgen_R=FChle?= <j-r@online.de>
This tries to be more to the point while also including a pointer on how to
unstage changes from the index.
Since this header is printed in two different code paths and the name of the
reference commit is needed for the unstage part, provide a new printing
function.
Signed-off-by: Jürgen Rühle <j-r@online.de>
---
wt-status.c | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 34be91b..98ca135 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -53,6 +53,18 @@ void wt_status_prepare(struct wt_status *s)
s->untracked = 0;
}
+static void wt_status_print_cached_header(const char *reference)
+{
+ const char *c = color(WT_STATUS_HEADER);
+ color_printf_ln(c, "# Cached changes to be committed:");
+ if (reference) {
+ color_printf_ln(c, "# (use \"git reset %s <file>...\" and \"git rm --cached <file>...\" to unstage)", reference);
+ } else {
+ color_printf_ln(c, "# (use \"git rm --cached <file>...\" to unstage)");
+ }
+ color_printf_ln(c, "#");
+}
+
static void wt_status_print_header(const char *main, const char *sub)
{
const char *c = color(WT_STATUS_HEADER);
@@ -147,8 +159,7 @@ static void wt_status_print_updated_cb(struct diff_queue_struct *q,
if (q->queue[i]->status == 'U')
continue;
if (!shown_header) {
- wt_status_print_header("Added but not yet committed",
- "will commit");
+ wt_status_print_cached_header(s->reference);
s->commitable = 1;
shown_header = 1;
}
@@ -179,8 +190,7 @@ void wt_status_print_initial(struct wt_status *s)
read_cache();
if (active_nr) {
s->commitable = 1;
- wt_status_print_header("Added but not yet committed",
- "will commit");
+ wt_status_print_cached_header(NULL);
}
for (i = 0; i < active_nr; i++) {
color_printf(color(WT_STATUS_HEADER), "#\t");
--
1.5.0.rc0.g31e2
^ permalink raw reply related
* [PATCH 1/4] Clarify syntax and role of git-add in status output
From: Juergen Ruehle @ 2007-01-02 19:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jürgen Rühle
In-Reply-To: <1167765983316-git-send-email-j.ruehle@bmiag.de>
From: =?iso-8859-1?q?J=FCrgen_R=FChle?= <j-r@online.de>
This uses the actual (simplified) synopsis line from the git-add man page and
advertises its incremental nature.
Signed-off-by: Jürgen Rühle <j-r@online.de>
---
wt-status.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index db42738..34be91b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -15,7 +15,7 @@ static char wt_status_colors[][COLOR_MAXLEN] = {
"\033[31m", /* WT_STATUS_CHANGED: red */
"\033[31m", /* WT_STATUS_UNTRACKED: red */
};
-static const char* use_add_msg = "use \"git add file1 file2\" to include for commit";
+static const char* use_add_msg = "use \"git add <file>...\" to incrementally add content to commit";
static int parse_status_slot(const char *var, int offset)
{
--
1.5.0.rc0.g31e2
^ permalink raw reply related
* [PATCH/RFC] Assorted small changes to runstatus
From: Juergen Ruehle @ 2007-01-02 19:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
As a regular user of git-status I'd like to propose some small changes and a
fix:
- wording changes to the section headers
- more context awareness in the nothing-to-commit line
- fix runstatus breakage when amending a root commit
Additional Notes:
- if git-reset <commit> <path> provided the ability to remove path from the
index (if not present in commit) runstatus could advertise reset as the
universal unstaging tool (in the non-initial-commit case)
(this is similar to the recent request on the list to allow
git-commit -o <path> to commit removal of path)
- IMO git-rm without -f should not remove anything if HEAD doesn't exist
(i.e. from the initial commit); this might be a bug
^ permalink raw reply
* Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior
From: Jakub Narebski @ 2007-01-02 19:22 UTC (permalink / raw)
To: git
In-Reply-To: <560316.34562.qm@web31812.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> Luben Tuikov <ltuikov@yahoo.com> writes:
>>
>>> Questions:
>>>
>>> What is the reasonining of defining branch.<name>.merge to point
>>> to the "remote's setup"?
>>
>> See list archives.
>>
>> Because you are not required to use remote tracking branches.
>
> Then why does it point to the _remote_ mapping? One shouldn't
> care what it is, and how it looks in the remote repo. That is
> handled by [remote]. In [branch] I shouldn't have to have any
> absolute references, i.e. branch.<name>.remote points to [remote],
> and branch.<name>.merge should only give a _branch_ name,
> whose remote-to-local mapping (which preserves the branch name)
> can be found by dereferencing branch.<name>.remote to get to
> remote.<rname>.fetch.
Once again: if you _don't_ have _local_ tracking branch, so you _must_
use _remote_ name.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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