* Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref
From: Sitaram Chamarty @ 2011-09-25 12:05 UTC (permalink / raw)
To: Pang Yan Han, Sitaram Chamarty, git, Junio C Hamano,
Shawn O. Pearce, Jeff
In-Reply-To: <20110925094822.GA1702@myhost>
On Sun, Sep 25, 2011 at 3:18 PM, Pang Yan Han <pangyanhan@gmail.com> wrote:
> On Sun, Sep 25, 2011 at 01:28:31PM +0530, Sitaram Chamarty wrote:
[snip]
>> It doesn't make sense to disable only the update hook. And although I
>> did not come right out and say it, it is the post-update that I care
>> about. If that still runs, my "issue" still exists.
> Um I'm rather new to Git and the reason why I didn't reply this initially was
> because I didn't know what to reply. Sorry but you sound rather aggressive and
> I was really taken aback by this.
Sorry if I sounded aggressive; I was going to brevity, and levity suffered :-)
[snip lots of stuff about new approach]
> What do you think of this approach (if it's even correct)?
I'm sorry again but it's been almost 2 decades since I did any serious
C and I've never dug into git internals, so I can't tell you if you're
even on the right track. You should wait for one of the other folks
you cc-d to weigh in with their opinions.
Personally, anytime someone says "disable the update hook" I get very
worried -- I've got a heck of a lot invested in update hooks ;-)
I wasn't even *asking* about disabling that; I was asking about
*post*-update, which you didn't even address in your code.
From a philosophical point of view, update and pre-receive *check*
things to make sure everything is OK. IMO they should be allowed to
run even if the ref being deleted doesn't exist -- that could well be
an error condition that the guy who owns the repo wants to trap and
alert himself to in some special way. I would *not* like them
disabled.
Post-{update,receive} are for *after* a successful push. My
suggestion would be to make sure the inputs supplied to those hooks
(via STDIN for post-receive, and as arguments in case of post-update)
reflect this -- only successfully updated refs are sent in as args.
This might mean that in the case of 'git push origin
:refs/heads/non-existent-ref' the post-receive hook would run but
STDIN would be empty, and post-update would run but have no arguments.
That is, IMO, the correct way to deal with this.
^ permalink raw reply
* [PATCH] git-completion: offer references for 'git reflog'
From: Michael Schubert @ 2011-09-25 10:42 UTC (permalink / raw)
To: git
'git reflog <ref>' is a valid command, therefore offer reference
completion.
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8648a36..63d0f08 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1774,7 +1774,7 @@ _git_reflog ()
local subcommand="$(__git_find_on_cmdline "$subcommands")"
if [ -z "$subcommand" ]; then
- __gitcomp "$subcommands"
+ __gitcomp "$subcommands $(__git_refs)"
else
__gitcomp "$(__git_refs)"
fi
--
1.7.7.rc3
^ permalink raw reply related
* Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref
From: Pang Yan Han @ 2011-09-25 9:48 UTC (permalink / raw)
To: Sitaram Chamarty
Cc: git, Junio C Hamano, Shawn O. Pearce, Jeff King,
Johannes Schindelin
In-Reply-To: <CAMK1S_hadzaqixaW3Fx81pf=hVsvAMpVvVGqVtZ8ncfUsie_9w@mail.gmail.com>
On Sun, Sep 25, 2011 at 01:28:31PM +0530, Sitaram Chamarty wrote:
> On Sun, Sep 25, 2011 at 10:36 AM, Pang Yan Han <pangyanhan@gmail.com> wrote:
> > Hi list,
> >
> > Currently, receive-pack runs the pre-receive, update, post-receive and
> > post-update hooks during a push to delete corrupt or non-existent refs, eg:
> >
> > git push origin :refs/heads/foo
> >
> > where refs/heads/foo is missing from the remote origin.
> >
> > The issue is reported here [1]
>
> I did not report an issue. I asked if this was expected and could be
> relied upon. I'm actually happy with the current behaviour because it
> solves a problem very neatly for me, but before documenting it I
> wanted to make sure it would not one day disappear.
>
> > This is a patch series which teaches receive-pack not to run update hook for
> > corrupt or non existent refs during a push.
> >
> > Patch 1/2 isn't really relevant to the topic. It's just something I stumbled
> > across while reading the code. It removes a redundant assignment in the is_url
> > function.
> >
> > Patch 2/2 teaches receive-pack not to run update hook for corrupt or non
> > existent refs. In summary, I reordered the statements in the update function
> > so that the update hook is not run for corrupt / non existent refs.
> >
> > Perhaps this isn't a good enough solution since the pre-receive, post-receive
> > and post-update hooks are still run. Also the tests aren't exactly good looking.
>
> It doesn't make sense to disable only the update hook. And although I
> did not come right out and say it, it is the post-update that I care
> about. If that still runs, my "issue" still exists.
Um I'm rather new to Git and the reason why I didn't reply this initially was
because I didn't know what to reply. Sorry but you sound rather aggressive and
I was really taken aback by this.
I've taken a look at the code again and here's another approach which will
result in heavier changes to builtin/receive-pack and may possibly work:
Check through the list of refs to be updated before even executing the
pre receive hook. Ensure that there is at least one "valid" ref update.
Essentially this is kind of like "dry running" the update function.
One way to do it is to shift the bulk of work determining valid and invalid
ref updates from the update function to a separate function.
We maintain 2 lists, one to store valid refs to be updated and another to
store non-existent/corrupt refs which will be deleted. Specifically, we will
be storing 'struct command'.
The update function can be cut down to these parts:
- determining namespaced_name
- lock_any_ref_for_update
- write_ref_sha1
The pre receive hook will only be executed if the list containing valid ref
pushes is non-empty. Same goes for the post receive and post update hooks.
What do you think of this approach (if it's even correct)?
>
> > Any advice is highly appreciated. Thanks!
> >
> > [1] http://thread.gmane.org/gmane.comp.version-control.git/181942
> >
> > Pang Yan Han (2):
> > is_url: Remove redundant assignment
> > receive-pack: Don't run update hook for corrupt or nonexistent ref
> >
> > builtin/receive-pack.c | 50 +++++++++++++++++++++++++++--------------------
> > t/t5516-fetch-push.sh | 33 +++++++++++++++++++++++++++++++
> > url.c | 1 -
> > 3 files changed, 62 insertions(+), 22 deletions(-)
> >
> > --
> > 1.7.7.rc3.2.g29f2e6
> >
> >
>
>
>
> --
> Sitaram
^ permalink raw reply
* Re: [PATCH/RFC 1/2] is_url: Remove redundant assignment
From: Tay Ray Chuan @ 2011-09-25 9:26 UTC (permalink / raw)
To: Pang Yan Han
Cc: git, Junio C Hamano, Shawn O. Pearce, Jeff King, Sitaram Chamarty,
Johannes Schindelin
In-Reply-To: <1316927182-14212-2-git-send-email-pangyanhan@gmail.com>
On Sun, Sep 25, 2011 at 1:06 PM, Pang Yan Han <pangyanhan@gmail.com> wrote:
> Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
> ---
> url.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/url.c b/url.c
> index 3e06fd3..d2e17e6 100644
> --- a/url.c
> +++ b/url.c
> @@ -22,7 +22,6 @@ int is_url(const char *url)
>
> if (!url)
> return 0;
> - url2 = url;
> first_slash = strchr(url, '/');
>
> /* Input with no slash at all or slash first can't be URL. */
Looks correct. Perhaps you could mention in the patch message that
There are no operations on url2 until another assignment to it later
at line 41.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref
From: Sitaram Chamarty @ 2011-09-25 7:58 UTC (permalink / raw)
To: Pang Yan Han
Cc: git, Junio C Hamano, Shawn O. Pearce, Jeff King,
Johannes Schindelin
In-Reply-To: <1316927182-14212-1-git-send-email-pangyanhan@gmail.com>
On Sun, Sep 25, 2011 at 10:36 AM, Pang Yan Han <pangyanhan@gmail.com> wrote:
> Hi list,
>
> Currently, receive-pack runs the pre-receive, update, post-receive and
> post-update hooks during a push to delete corrupt or non-existent refs, eg:
>
> git push origin :refs/heads/foo
>
> where refs/heads/foo is missing from the remote origin.
>
> The issue is reported here [1]
I did not report an issue. I asked if this was expected and could be
relied upon. I'm actually happy with the current behaviour because it
solves a problem very neatly for me, but before documenting it I
wanted to make sure it would not one day disappear.
> This is a patch series which teaches receive-pack not to run update hook for
> corrupt or non existent refs during a push.
>
> Patch 1/2 isn't really relevant to the topic. It's just something I stumbled
> across while reading the code. It removes a redundant assignment in the is_url
> function.
>
> Patch 2/2 teaches receive-pack not to run update hook for corrupt or non
> existent refs. In summary, I reordered the statements in the update function
> so that the update hook is not run for corrupt / non existent refs.
>
> Perhaps this isn't a good enough solution since the pre-receive, post-receive
> and post-update hooks are still run. Also the tests aren't exactly good looking.
It doesn't make sense to disable only the update hook. And although I
did not come right out and say it, it is the post-update that I care
about. If that still runs, my "issue" still exists.
> Any advice is highly appreciated. Thanks!
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/181942
>
> Pang Yan Han (2):
> is_url: Remove redundant assignment
> receive-pack: Don't run update hook for corrupt or nonexistent ref
>
> builtin/receive-pack.c | 50 +++++++++++++++++++++++++++--------------------
> t/t5516-fetch-push.sh | 33 +++++++++++++++++++++++++++++++
> url.c | 1 -
> 3 files changed, 62 insertions(+), 22 deletions(-)
>
> --
> 1.7.7.rc3.2.g29f2e6
>
>
--
Sitaram
^ permalink raw reply
* Git for animation studio
From: Will Hoag @ 2011-09-24 21:43 UTC (permalink / raw)
To: git
Hi,
I'm doing researching for an online version control systems for our developing studio. Wondering how git could work for us in regards to large files, lots of data, lots of collaboration etc. I have a basic idea of how it works, but I'm very new to version control. Many thanks for your help.
Best,
Will Hoag
^ permalink raw reply
* Re: [PATCH 3/6] branch: teach --edit-description option
From: Nguyen Thai Ngoc Duy @ 2011-09-25 5:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62kjulkf.fsf@alter.siamese.dyndns.org>
On Sat, Sep 24, 2011 at 5:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Thu, Sep 22, 2011 at 03:09:19PM -0700, Junio C Hamano wrote:
>>> + if (launch_editor(git_path(edit_description), &buf, NULL)) {
>>> + strbuf_release(&buf);
>>> + return -1;
>>> + }
>>> + stripspace(&buf, 1);
>>> +
>>> + strbuf_addf(&name, "branch.%s.description", branch_name);
>>> + status = git_config_set(name.buf, buf.buf);
>>
>> I suppose a Windows editor mave save the description with \r\n
>> ending. Perhaps a patch like this to avoid messing up config file?
>
> Doesn't stripspace() cleanse that already?
>
Yes, isspace() indeed treats \r as a space and stripspace() does the
right thing.
--
Duy
^ permalink raw reply
* [PATCH/RFC 2/2] receive-pack: Don't run update hook for corrupt or nonexistent ref
From: Pang Yan Han @ 2011-09-25 5:06 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Shawn O. Pearce, Jeff King, Sitaram Chamarty,
Johannes Schindelin, Pang Yan Han
In-Reply-To: <1316927182-14212-1-git-send-email-pangyanhan@gmail.com>
Teach receive-pack not to run update hook for a corrupt or nonexistent ref.
In addition, update the warning message for deleting a corrupt or nonexistent
ref from:
"Allowing deletion of corrupt ref"
to:
"Allowing deletion of corrupt/nonexistent ref"
Noticed-by: Sitaram Chamarty <sitaramc@gmail.com>
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
---
builtin/receive-pack.c | 50 +++++++++++++++++++++++++++--------------------
t/t5516-fetch-push.sh | 33 +++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 21 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index ae164da..a9385cf 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -346,6 +346,17 @@ static void refuse_unconfigured_deny_delete_current(void)
rp_error("%s", refuse_unconfigured_deny_delete_current_msg[i]);
}
+static const char *delete_null_sha1_ref(const char *namespaced_name,
+ const char *name,
+ unsigned char *old_sha1)
+{
+ if (delete_ref(namespaced_name, old_sha1, 0)) {
+ rp_error("failed to delete %s", name);
+ return "failed to delete";
+ }
+ return NULL; /* good */
+}
+
static const char *update(struct command *cmd)
{
const char *name = cmd->ref_name;
@@ -438,33 +449,30 @@ static const char *update(struct command *cmd)
return "non-fast-forward";
}
}
+
+ /* Don't run update hook for corrupt/nonexistent ref */
+ if (is_null_sha1(new_sha1) && !parse_object(old_sha1)) {
+ rp_warning("Allowing deletion of corrupt/nonexistent ref.");
+ old_sha1 = NULL;
+ return delete_null_sha1_ref(namespaced_name, name, old_sha1);
+ }
+
if (run_update_hook(cmd)) {
rp_error("hook declined to update %s", name);
return "hook declined";
}
- if (is_null_sha1(new_sha1)) {
- if (!parse_object(old_sha1)) {
- rp_warning("Allowing deletion of corrupt ref.");
- old_sha1 = NULL;
- }
- if (delete_ref(namespaced_name, old_sha1, 0)) {
- rp_error("failed to delete %s", name);
- return "failed to delete";
- }
- return NULL; /* good */
- }
- else {
- lock = lock_any_ref_for_update(namespaced_name, old_sha1, 0);
- if (!lock) {
- rp_error("failed to lock %s", name);
- return "failed to lock";
- }
- if (write_ref_sha1(lock, new_sha1, "push")) {
- return "failed to write"; /* error() already called */
- }
- return NULL; /* good */
+ if (is_null_sha1(new_sha1))
+ return delete_null_sha1_ref(namespaced_name, name, old_sha1);
+
+ lock = lock_any_ref_for_update(namespaced_name, old_sha1, 0);
+ if (!lock) {
+ rp_error("failed to lock %s", name);
+ return "failed to lock";
}
+ if (write_ref_sha1(lock, new_sha1, "push"))
+ return "failed to write"; /* error() already called */
+ return NULL; /* good */
}
static char update_post_hook[] = "hooks/post-update";
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 3abb290..b7a74e3 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -40,6 +40,20 @@ mk_test () {
)
}
+mk_test_with_update_hook () {
+ mk_test "$@" &&
+ (
+ cd testrepo &&
+ mkdir .git/hooks &&
+ cd .git/hooks &&
+ cat >update <<'EOF'
+#!/bin/sh
+printf %s "$@" >>update.args
+EOF
+ chmod u+x update
+ )
+}
+
mk_child() {
rm -rf "$1" &&
git clone testrepo "$1"
@@ -559,6 +573,25 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'deleting existing ref triggers update hook' '
+ mk_test_with_update_hook heads/master &&
+ (
+ cd testrepo &&
+ git rev-parse --verify refs/heads/master &&
+ git config receive.denyDeleteCurrent warn
+ ) &&
+ git push testrepo :refs/heads/master &&
+ (cd testrepo && test_must_fail git rev-parse --verify refs/heads/master) &&
+ (cd testrepo/.git && test -s update.args)
+'
+
+test_expect_success 'deleting nonexistent ref does not trigger update hook' '
+ mk_test_with_update_hook heads/master &&
+ rm -f testrepo/.git/objects/??/* &&
+ git push testrepo :refs/heads/master &&
+ (cd testrepo/.git && ! test -f update.args)
+'
+
test_expect_success 'allow deleting a ref using --delete' '
mk_test heads/master &&
(cd testrepo && git config receive.denyDeleteCurrent warn) &&
--
1.7.7.rc3.2.g29f2e6
^ permalink raw reply related
* [PATCH/RFC 1/2] is_url: Remove redundant assignment
From: Pang Yan Han @ 2011-09-25 5:06 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Shawn O. Pearce, Jeff King, Sitaram Chamarty,
Johannes Schindelin, Pang Yan Han
In-Reply-To: <1316927182-14212-1-git-send-email-pangyanhan@gmail.com>
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
---
url.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/url.c b/url.c
index 3e06fd3..d2e17e6 100644
--- a/url.c
+++ b/url.c
@@ -22,7 +22,6 @@ int is_url(const char *url)
if (!url)
return 0;
- url2 = url;
first_slash = strchr(url, '/');
/* Input with no slash at all or slash first can't be URL. */
--
1.7.7.rc3.2.g29f2e6
^ permalink raw reply related
* [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref
From: Pang Yan Han @ 2011-09-25 5:06 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Shawn O. Pearce, Jeff King, Sitaram Chamarty,
Johannes Schindelin, Pang Yan Han
Hi list,
Currently, receive-pack runs the pre-receive, update, post-receive and
post-update hooks during a push to delete corrupt or non-existent refs, eg:
git push origin :refs/heads/foo
where refs/heads/foo is missing from the remote origin.
The issue is reported here [1]
This is a patch series which teaches receive-pack not to run update hook for
corrupt or non existent refs during a push.
Patch 1/2 isn't really relevant to the topic. It's just something I stumbled
across while reading the code. It removes a redundant assignment in the is_url
function.
Patch 2/2 teaches receive-pack not to run update hook for corrupt or non
existent refs. In summary, I reordered the statements in the update function
so that the update hook is not run for corrupt / non existent refs.
Perhaps this isn't a good enough solution since the pre-receive, post-receive
and post-update hooks are still run. Also the tests aren't exactly good looking.
Any advice is highly appreciated. Thanks!
[1] http://thread.gmane.org/gmane.comp.version-control.git/181942
Pang Yan Han (2):
is_url: Remove redundant assignment
receive-pack: Don't run update hook for corrupt or nonexistent ref
builtin/receive-pack.c | 50 +++++++++++++++++++++++++++--------------------
t/t5516-fetch-push.sh | 33 +++++++++++++++++++++++++++++++
url.c | 1 -
3 files changed, 62 insertions(+), 22 deletions(-)
--
1.7.7.rc3.2.g29f2e6
^ permalink raw reply
* Re: git svn with non-standard svn layout
From: Phil Hord @ 2011-09-25 3:45 UTC (permalink / raw)
To: Chris Harris; +Cc: git
In-Reply-To: <CANPpUWxnp3-ySO3oBEsWTQA=oWXEzKS1bddP9LjAsR1EyPxbVQ@mail.gmail.com>
On Sat, Sep 24, 2011 at 2:37 PM, Chris Harris <chris.harris123@gmail.com> wrote:
> I am using git version 1.7.6.4 built from the latest stable source on
> github. Running Ubuntu with kernel 2.6.38-11-generic
>
> I can't seem to git git svn to see my branches correctly.
> Unfortunately my svn repository is not open source, so I can not post
> it here, but I will try to explain my issue.
> We use a non standard svn layout like the following
> branches
> V4.1
> V4.1.0
> V4.1.1
> dev
>
>
> dev is our trunk, and our branches have 2 levels.
> I first use git init, then setup my config as follows
> [svn-remote "svn"]
> url = file:///home/chris/svnrepo
> fetch = dev:refs/remotes/trunk
> branches = branches/V4.1/{V4.1.1}:refs/remotes/branches/*
> For this example I am just trying to make a single branch work.
> After a fetch all revisions are ok. master correctly points to
> remotes/trunk,but gitk shows the following:
>
> o remotes/branches/V4.1.1
> |
> o some commit
> |
> |
> | o master - remotes/trunk
> | |
> | o another commit
> | /
> |
> etc
> ( sorry for the bad ascii art. )
> My issue is that trunk ( master ) appears to be a branch from V4.1.1
> instead of V4.1.1 being a branch from trunk ( master )
In git's estimation, there is no difference between these two cases.
Visually you may think there is a difference, but graphically (in the
"network graph" sense of the word) they are exactly the same thing.
Consider this history:
o---o---A---B---C <== trunk
\
D---E---F <== V4.1.1
Compare it to this "other" history:
B---C <== trunk
/
o---o---A---D---E---F <== V4.1.1
You might say the first one looks "right" and the second one looks
"wrong". But in fact, they are the same graph. They both say that
B's parent is A and D's parent is A. B and D share a common ancestor
at A.
Here's another view:
B---C <== trunk
/
o---o---A
\
D---E---F <== V4.1.1
You may want to read this nice description of the DAG:
http://eagain.net/articles/git-for-computer-scientists/
> git log --graph shows the same structure.
> Any suggestions on how to configure this so git svn maps my
> non-standard layout correctly?
Try git log --graph --date-order to see a slightly different take on things.
Phil
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Martin von Zweigbergk @ 2011-09-25 3:25 UTC (permalink / raw)
To: Ramkumar Ramachandra, Thomas Rast
Cc: Martin von Zweigbergk, Junio C Hamano, Francis Moreau,
Michael J Gruber, git
In-Reply-To: <CALkWK0mggSNoxxqzUaGp1-AxGWSpCb0HnRmBxSkcVrHnhwMr1Q@mail.gmail.com>
Hi Ram and Thomas,
On Sat, 24 Sep 2011, Ramkumar Ramachandra wrote:
> Martin von Zweigbergk writes:
> > [...] We also want it to
> > work with --root, so we can not use git-cherry.
I think I was confused here; git-cherry should work just fine. Simply
leaving out the limit, or setting it to $onto, makes the walk go all
the way to the roots. After thinking a bit more about this, I'm
instead wondering what the purpose of the --root flag to git-rebase
is. Thomas introduced it in 190f532 (rebase: learn to rebase root
commit, 2009-01-05).
If I understand correctly, it was introduced to solve exactly the same
reason problem that made Francis start this thread -- to avoid
re-applying patches that are already in $onto. In Thomas's patch,
git-rebase started passing $onto..$orig_head instead of
$upstream..$orig_head to git-format-patch. It also started passing
--root to git-format-patch, but that was made unneccessary a few days
later in 68c2ec7 (format-patch: show patch text for the root commit,
2009-01-10).
After my patches (that are not yet ready) that calculate revisions as
"git cherry $onto $orig_head $upstream", I don't think there should be
any need for the --root flag. The only place the flag is checked now
(in my current work tree, that is) is when deciding how to interpret
the remaining arguments. Although I have not tried (temporarily)
rewriting all the test cases from
git rebase --root --onto upstream branch
to
git rebase upstream branch
, I think it should work. What do you think, Thomas? I saw that
"--root" is also passed to the hook. Should that value be passed to
the hook also when the old base is not explicitly a root (by "rebase
--root"), but only implicitly so (by an $onto that is disjoint from
$branch)?
Martin
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-25 2:16 UTC (permalink / raw)
To: git
In-Reply-To: <201109242259.p8OMxqIM026259@no.baka.org>
Seth Robertson wrote:
> As I explained on IRC, you can use the following workflow to create a
> three way merge.
>
> git stash
> git fetch
> git merge @{u} stash
> git mergetool
> git stash drop
>
> You can then do whatever other work you want. You can repeat this
> workflow as often as you want. When you are done, then you can
> commit:
>
> git commit -a -m "My important work"
>
> This is of course easily scriptable so it becomes one command to you.
> And since you mentioned it, if the merge went poorly and you wanted to
> start over (only before you dropped the stash of course), you can:
>
> git reset --hard HEAD
> git merge @{u} stash
Thanks. It's a shame, however, that Git makes the user jump through hoops
to achieve such a simple thing.
> Of course, I would recommend you consider some of the more gitish
> workflows.
And that, I feel, is a problem with Git. In some cases, you can't do
things how you want -- you have to do things how Git wants.
Another example of this is the lack of support for anonymous branching as
part of a normal workflow in Git. Anonymous branching is very powerful and
very simple. I use it all the time in Mercurial.
> Commit early and often. `git pull --rebase` as often as
> you want, and then use `git rebase -i @{u}^` to squash all of your
> in-progress commits together. With appropriate in-progress commit
> message crafting, you can use the --autosquash functionality of
> git-rebase to make this process easier.
Thanks for the ideas, but they don't solve my particular problem. The
reason I regularly pull with local changes is that I like to use clones for
short-term branching (because it's powerful and flexible -- for example,
when I create my "TryFeatureX" clone, I have two versions of my project on
disk, and I can run them side by side).
In order to avoid pointless merges, I sometimes don't commit until I've
pulled. Sure, I could commit and then rebase instead, but, in this
situation, rebasing is effectively merging and committing in one step.
With my workflow, however, after I merge, I can still make changes (and do
other stuff like running unit tests) before finally committing.
^ permalink raw reply
* Re: Where is information of "git read-tree" stored?
From: David Aguilar @ 2011-09-25 1:30 UTC (permalink / raw)
To: Manuel Reimer; +Cc: git, Junio C Hamano
In-Reply-To: <7vobyg89rh.fsf@alter.siamese.dyndns.org>
On Mon, Sep 19, 2011 at 03:09:22PM -0700, Junio C Hamano wrote:
>
> To a certain degree, the point of a tool is that the user does not need to
> know about the details, but if you are interested...
git-subtree allows you to not have to know about the details:
https://github.com/apenwarr/git-subtree
https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt
git-subtree, combined with Junio's wonderful write-up below,
should get you on the right track.
> Suppose you have this tree structure in your "original" project:
>
> Documentation/README.txt
> hello.c
> Makefile
>
> and then somebody else has this structure in his project (in your case, it
> may happen to be stored in SVN but once it is slurped in a git repository,
> it does not matter):
>
> goodbye.c
> Makefile
>
> Further suppose that you would want to end up with this tree structure:
>
> Documentation/README.txt
> Makefile
> hello.c
> imported/Makefile
> imported/goodbye.c
>
> i.e. you would want to move stuff that came from the other project in imported/
> hierarchy. There may be many other files, and even subdirectories, in the
> other project, but they all are shifted one level down and placed in imported/
> hierarchy.
>
> The first four steps of the howto is to create such a final tree structure
> and make a merge commit out of that tree.
>
> After you update your project (which now has both the original files such
> as hello.c etc., may have added new files, and may even have updated stuff
> inside imported/ hierarchy) and the other side updated their project (e.g.
> it may have updated goodbye.c whose change you would want to carry over to
> your imported/goodbye.c, or it may have added a new file welcome.c, which
> you would want to import as imported/welcome.c), you would invoke "pull -s
> subtree", which in turn runs "merge -s subtree".
>
> The subtree strategy first compares the shapes of two trees being merged,
> and tries to find how much they have to be shifted to match. Your tree
> may now have:
>
> Documentation/README.txt
> Makefile
> hello.h (added)
> hello.c
> imported/Makefile
> imported/goodbye.c
>
> while the other side may now have:
>
> goodbye.c
> Makefile
> welcome.c
>
> The subtree strategy notices that by prefixing "imported/" in front of the
> paths, the tree from the other side will match the shape of the subtree
> you have under "imported/". Thus it can pair:
>
> their "goodbye.c" with your "imported/goodbye.c"
> their "Makefile" with your "imported/Makefile"
> their "welcome.c" with your "imported/welcome.c"
>
> and merge the changes. The common ancestor commit of this merge will be
> the initial merge you made with the first 4-step, so the three-way merge
> logic would notice that there wasn't "welcome.c" in the beginning, they
> added that path, while you did not do anything to the path that
> corresponds to it (namely, "imported/welcome.c"), so the new "welcome.c"
> file from the other project would simply be copied as "imported/welcome.c"
> to your tree, and the change they made to "goodbye.c" and your changes you
> made to your "imported/goodbye.c" will be merged and result is recorded in
> your "imported/goodbye.c".
>
> If "compares the shape and figures out how much to shift" makes you feel
> uneasy (and it probably should), you can give an explicit directory prefix
> as the backend option "subtree" (see "git merge help" for details).
--
David
^ permalink raw reply
* Re: [PATCH] mergetool: Use args as pathspec to unmerged files
From: David Aguilar @ 2011-09-25 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathon Mah, git, Dan McGee
In-Reply-To: <7vaaa4fdix.fsf@alter.siamese.dyndns.org>
On Fri, Sep 16, 2011 at 01:17:10PM -0700, Junio C Hamano wrote:
> Jonathon Mah <me@JonathonMah.com> writes:
>
> > Mergetool now treats its path arguments as a pathspec (like other git
> > subcommands), restricting action to the given files and directories.
> > Files matching the pathspec are filtered so mergetool only acts on
> > unmerged paths; previously it would assume each path argument was in an
> > unresolved state, and get confused when it couldn't check out their
> > other stages.
> >
> > Running "git mergetool subdir" will prompt to resolve all conflicted
> > blobs under subdir.
> >
> > Signed-off-by: Jonathon Mah <me@JonathonMah.com>
>
> It looks like this simplifies the code quote a bit and make the result
> easier to follow ;-) Nicely done.
>
> As nobody reads from a pipe in while loop and runs merge_file or prompt
> inside, there no longer is a reason to redirect the original standard
> input and make it available, hence we could perhaps add this patch on top
> of your change.
>
> Ack from mergetool/difftool folks?
I've been on vacation and am just catching up with my git mail.
I just tested:
6bed9767daaa "Merge branch 'jm/mergetool-pathspec' into pu"
and it looks good to me.
FWIW,
Acked-by: David Aguilar <davvid@gmail.com>
Being able to do "git mergetool -- subdir" is very nice!
Thanks guys,
--
David
^ permalink raw reply
* [PATCH] allow display of the name of the remote the current branch
From: Tom Lazar @ 2011-09-24 23:30 UTC (permalink / raw)
To: spearce; +Cc: git
---
contrib/completion/git-completion.bash | 17 +++++++++++++++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8648a36..dd34d01 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -60,6 +60,11 @@
# per-repository basis by setting the bash.showUpstream config
# variable.
#
+# If you would like to see the name of the remote that the current branch
+# is tracking, set GIT_PS1_SHOWBRANCHREMOTE to a nonempty value. If the
+# current branch is tracking a remote branch, the name of that remote is
+# displayed before the branch name, separated by a colon.
+#
#
# To submit patches:
#
@@ -217,7 +222,6 @@ __git_ps1_show_upstream ()
p=" u+${count#* }-${count% *}" ;;
esac
fi
-
}
@@ -278,6 +282,8 @@ __git_ps1 ()
local u=""
local c=""
local p=""
+ local remote=""
+ local branch=""
if [ "true" = "$(git rev-parse --is-inside-git-dir 2>/dev/null)" ]; then
if [ "true" = "$(git rev-parse --is-bare-repository 2>/dev/null)" ]; then
@@ -309,10 +315,17 @@ __git_ps1 ()
if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
__git_ps1_show_upstream
fi
+ branch=${b##refs/heads/}
+ if [ -n "${GIT_PS1_SHOWBRANCHREMOTE-}" ]; then
+ remote=`git config --get branch.$branch.remote`
+ if [[ $remote ]]; then
+ remote=$remote:
+ fi
+ fi
fi
local f="$w$i$s$u"
- printf "${1:- (%s)}" "$c${b##refs/heads/}${f:+ $f}$r$p"
+ printf "${1:- (%s)}" "$c$remote$branch${f:+ $f}$r$p"
fi
}
--
1.7.5.4
^ permalink raw reply related
* Re: More Beginning Git Questions
From: Seth Robertson @ 2011-09-24 22:59 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <1m2c90ds9e46c.7agk88pbgjl8$.dlg@40tude.net>
In message <1m2c90ds9e46c.7agk88pbgjl8$.dlg@40tude.net>, tactical writes:
Frans Klaver wrote:
>> Mercurial allows this, and it's a very powerful feature. After reading
>> this thread, I could not believe Git didn't pulling with local changes,
>> and so I tried it, and also asked on IRC -- and it seems that Git really
>> doesn't.
>
> Git doesn't do it implicitly. Be explicit about it
>
> $ git stash
> $ git pull
> $ git stash pop
>
> seems to do exactly what you want.
Does popping the stash allow for a three-way merge? If not, this doesn't
really solve the problem.
As I explained on IRC, you can use the following workflow to create a
three way merge.
git stash
git fetch
git merge @{u} stash
git mergetool
git stash drop
You can then do whatever other work you want. You can repeat this
workflow as often as you want. When you are done, then you can
commit:
git commit -a -m "My important work"
This is of course easily scriptable so it becomes one command to you.
And since you mentioned it, if the merge went poorly and you wanted to
start over (only before you dropped the stash of course), you can:
git reset --hard HEAD
git merge @{u} stash
And then continue with the rest of the workflow above.
Of course, I would recommend you consider some of the more gitish
workflows. Commit early and often. `git pull --rebase` as often as
you want, and then use `git rebase -i @{u}^` to squash all of your
in-progress commits together. With appropriate in-progress commit
message crafting, you can use the --autosquash functionality of
git-rebase to make this process easier.
-Seth Robertson
^ permalink raw reply
* Re: how to remove unreachable objects?
From: Dieter Schön @ 2011-09-24 22:11 UTC (permalink / raw)
To: git
In-Reply-To: <20110919195335.GA31930@sigill.intra.peff.net>
Am 19.09.2011 um 21:53 schrieb Jeff King:
> On Mon, Sep 19, 2011 at 11:08:31AM +0200, dieter@schoen.or.at wrote:
>
>> this is my use case:
>> i create a repository and produce several commits on master.
>> then i go back to a certain tag and create a new branch, where i also
>> commit.
>> then i switch back to master and delete (-D) the other branch.
>> it should now be unreachable from within git (to prove its existence,
>> i remember a commit SHA1 on the dead branch).
>
> It will still be referenced by the HEAD reflog, won't it?
thanks to all that answered!
it was very helpful and i gained a bit more insight.
kind regards,
dieter
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-24 22:17 UTC (permalink / raw)
To: git
In-Reply-To: <op.v2byz2p80aolir@keputer.lokaal>
Frans Klaver wrote:
>> Mercurial allows this, and it's a very powerful feature. After reading
>> this thread, I could not believe Git didn't pulling with local changes,
>> and so I tried it, and also asked on IRC -- and it seems that Git really
>> doesn't.
>
> Git doesn't do it implicitly. Be explicit about it
>
> $ git stash
> $ git pull
> $ git stash pop
>
> seems to do exactly what you want.
Does popping the stash allow for a three-way merge? If not, this doesn't
really solve the problem.
Thanks
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-24 22:10 UTC (permalink / raw)
To: git
In-Reply-To: <m362khr6kh.fsf@localhost.localdomain>
Jakub Narebski wrote:
>>> > Generally Alice shouldn't have uncommitted changes when doing
>>> > "git pull".
>>>
>>> That's what the tutorial said but I'm trying to understand
>>> what happens if she does have uncommitted changes. I'm
>>> trying to understand the total picture.
>>
>> Mercurial allows this, and it's a very powerful feature.
>
> You *do* realize thet "hg pull" is "git fetch", don't you?
Yes. This is what I mean:
c:\test>hg diff
diff --git a/foo b/foo
--- a/foo
+++ b/foo
@@ -1,1 +1,2 @@
test
+new line
c:\test>hg incoming --patch clone
comparing with clone
searching for changes
changeset: 1:0a897c3462a8
tag: tip
user: tactical
date: Sat Sep 24 23:03:21 2011 +0100
summary: bar
diff --git a/foo b/foo
--- a/foo
+++ b/foo
@@ -1,1 +1,2 @@
test
+bar
c:\test>hg pull clone
pulling from clone
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
c:\test>hg update
merging foo
Now KDiff3 automagically appears (because of the line conflict).
>> After reading
>> this thread, I could not believe Git didn't pulling with local changes, and
>> so I tried it, and also asked on IRC -- and it seems that Git really
>> doesn't.
>>
>> If this is an important part of your workflow (as it is mine), I'd
>> recommend using Mercurial if possible.
>>
>
> So the question is if mercurial allows _merging_ with local
> changes... and from the thread it looks like git dies allow it, as
> long as changes are isolated from changes brought by merge.
For that reason, Git doesn't support my workflow at all.
> Anyway merging with local changes is an easy way to f**k up your
> changes in unrecoverable way, IMVHO...
Mercurial backs everything up before doing this merge, so if I do lose my
local changes, I can start over with this:
hg resolve --unmark --all
hg resolve --all
Now KDiff3 comes up again, with the same data as before. No data lost.
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Vitor Antunes @ 2011-09-24 21:35 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Sverre Rabbelier, git, David Barr, Dmitry Ivankov
In-Reply-To: <20110924193733.GB10955@elie>
On Sep 24, 2011 8:37 PM, "Jonathan Nieder" <jrnieder@gmail.com> wrote:
> Thanks. I must have missed the earlier discussion. What are the
> semantics of this command and its intended purpose? For example, what
> happens if the branch already existed or if there is a checkpoint
> (perhaps triggered by the impatient user sending SIGUSR1 to
> fast-import) before the "drop" command is processed?
In the tests I made there are checkpoints triggered before using the
command. I tried to remove the branch within fast-import variables as well
as the already processed objects in git.
This command is required because I need to reset a given branch multiple
times in order to be able to "guess" its origin commit in the parent branch.
To make this analysis I also need to use "checkpoint" at each try.
(Resending... apparently gmail Android app sends a HTML attachment)
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Dmitry Ivankov @ 2011-09-24 21:19 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Vitor Antunes, git, Sverre Rabbelier, David Barr
In-Reply-To: <20110924193733.GB10955@elie>
On Sun, Sep 25, 2011 at 1:37 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Vitor Antunes wrote:
>
>> The drop command deletes the given branch reference, allowing
>> fast-import to actively ignore it in the final checks.
>
> Thanks. I must have missed the earlier discussion. What are the
> semantics of this command and its intended purpose?
My guess is that if fast-import is used to manage a set of "remote"
branches, it should be able to delete branches. Then, it should
be allowed to do non-fastforward updates too (--force). Why can't
it just ignore branches deletion (considering --force)?
Random thoughts:
1. once 'drop' is executed, fast-import can't tell if the branch was
actually deleted. And moreover any attempt to read this branch
head becomes illegal (either it's missing in .git or fast-import is
instructed to use a dropped branch).
2. 'reset' command is a bit like proposed 'drop' but it never deletes
a branch ref. Consider following imports:
1) import branch topic
2) reset topic
3) import branch topic2 starting at topic (incorrect import)
If 1-3) is done in one fast-import process, the error is reported.
If 3) is done separately, it succeeds but the result is strange:
topic2 isn't started from scratch but from old "erased" topic.
So, maybe, reset should be fixed to erase branches on --force.
One more scenario is:
1) import topic
2) reset topic
3) import topic
If 1-3) go together - no error
If 3) goes separate - no error, but non-fastforward update.
Much more harmless, but still may look strange.
> For example, what
> happens if the branch already existed or if there is a checkpoint
> (perhaps triggered by the impatient user sending SIGUSR1 to
> fast-import) before the "drop" command is processed?
I think that actual ref deletion should take place in update_branch().
So all the cases would be handled as usual.
> Jonathan
>
^ permalink raw reply
* Re: More Beginning Git Questions
From: Jakub Narebski @ 2011-09-24 21:10 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <14gm3o851q0ad.1uoossmxgfyit.dlg@40tude.net>
tactical <a5158017@nepwk.com> writes:
> Jon Forrest wrote:
> > Jakub Narebski wrote:
> > > Generally Alice shouldn't have uncommitted changes when doing
> > > "git pull".
> >
> > That's what the tutorial said but I'm trying to understand
> > what happens if she does have uncommitted changes. I'm
> > trying to understand the total picture.
>
> Mercurial allows this, and it's a very powerful feature.
You *do* realize thet "hg pull" is "git fetch", don't you?
> After reading
> this thread, I could not believe Git didn't pulling with local changes, and
> so I tried it, and also asked on IRC -- and it seems that Git really
> doesn't.
>
> If this is an important part of your workflow (as it is mine), I'd
> recommend using Mercurial if possible.
>
So the question is if mercurial allows _merging_ with local
changes... and from the thread it looks like git dies allow it, as
long as changes are isolated from changes brought by merge.
Anyway merging with local changes is an easy way to f**k up your
changes in unrecoverable way, IMVHO...
--
Jakub Narębski
^ permalink raw reply
* Re: More Beginning Git Questions
From: Frans Klaver @ 2011-09-24 20:53 UTC (permalink / raw)
To: git
In-Reply-To: <14gm3o851q0ad.1uoossmxgfyit.dlg@40tude.net>
On Sat, 24 Sep 2011 22:22:31 +0200, tactical <a5158017@nepwk.com> wrote:
> Mercurial allows this, and it's a very powerful feature. After reading
> this thread, I could not believe Git didn't pulling with local changes,
> and so I tried it, and also asked on IRC -- and it seems that Git really
> doesn't.
Git doesn't do it implicitly. Be explicit about it
$ git stash
$ git pull
$ git stash pop
seems to do exactly what you want.
Cheers,
Frans
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-24 20:22 UTC (permalink / raw)
To: git
In-Reply-To: <4E7CCCA0.50909@gmail.com>
Jon Forrest wrote:
>> Generally Alice shouldn't have uncommitted changes when doing
>> "git pull".
>
> That's what the tutorial said but I'm trying to understand
> what happens if she does have uncommitted changes. I'm
> trying to understand the total picture.
Mercurial allows this, and it's a very powerful feature. After reading
this thread, I could not believe Git didn't pulling with local changes, and
so I tried it, and also asked on IRC -- and it seems that Git really
doesn't.
If this is an important part of your workflow (as it is mine), I'd
recommend using Mercurial if possible.
^ 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