* Re: GIT_EXTERNAL_DIFF invoked with undocumented calling convention after unstashing conflicts
From: Junio C Hamano @ 2007-09-30 19:59 UTC (permalink / raw)
To: Bruno Haible; +Cc: git
In-Reply-To: <200709302117.37422.bruno@clisp.org>
> "git diff --uncached" invokes the GIT_EXTERNAL_DIFF variable with just one
> argument (instead of 7 arguments, as documented) in a particular situation:
You are looking at an unmerged path.
'GIT_EXTERNAL_DIFF'::
When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
program named by it is called, instead of the diff invocation
described above. For a path that is added, removed, or modified,
'GIT_EXTERNAL_DIFF' is called with 7 parameters:
...
+
For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
parameter, <path>.
The script needs to decide how it wants to present an unmerged
path; the information on each unmerged stages can be read from
the output of "ls-files -u $thatpath".
^ permalink raw reply
* GIT_EXTERNAL_DIFF ignored after unstashing conflicts
From: Bruno Haible @ 2007-09-30 19:18 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]
Hi,
"git diff" ignores the GIT_EXTERNAL_DIFF variable in a particular situation:
when there are conflicts after "git stash apply".
To reproduce:
- Set environment variable GIT_EXTERNAL_DIFF to point to the attached
script.
- Make a clean gnulib checkout, 1 day old.
- Add a entry to the top of the ChangeLog.
- $ git pull
fails due a conflict.
- $ git stash
- $ git pull
- $ git stash apply
- $ git-diff | cat
yields:
diff --cc ChangeLog
index 443ad76,991c26b..0000000
--- a/ChangeLog
+++ b/ChangeLog
@@@ -1,7 -1,6 +1,11 @@@
2007-09-30 Bruno Haible <bruno@clisp.org>
++<<<<<<< Updated upstream:ChangeLog
+ * tests/test-getaddrinfo.c (AF_UNSPEC): Provide a fallback definition.
+ Needed on BeOS.
++=======
+ * Some other changes.
++>>>>>>> Stashed changes:ChangeLog
2007-09-30 Bruno Haible <bruno@clisp.org>
The script has not been called (witness: the echo command at its line 2).
Can it be called, like in the case of "git-diff --cached"?
Bruno
[-- Attachment #2: my-diff-for-git --]
[-- Type: application/x-shellscript, Size: 981 bytes --]
^ permalink raw reply
* GIT_EXTERNAL_DIFF invoked with undocumented calling convention after unstashing conflicts
From: Bruno Haible @ 2007-09-30 19:17 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]
Hi,
"git diff --uncached" invokes the GIT_EXTERNAL_DIFF variable with just one
argument (instead of 7 arguments, as documented) in a particular situation:
when there are conflicts after "git stash apply".
To reproduce:
- Set environment variable GIT_EXTERNAL_DIFF to point to the attached
script.
- Make a clean gnulib checkout, 1 day old.
- Add a entry to the top of the ChangeLog.
- $ git pull
fails due a conflict.
- $ git stash
- $ git pull
- $ git stash apply
- $ git-diff --cached | cat
yields:
my-diff-for-git ChangeLog
diff --cc ChangeLog
index 443ad76,991c26b..0000000
--- a/ChangeLog
+++ b/ChangeLog
@@@ -1,7 -1,6 +1,11 @@@
2007-09-30 Bruno Haible <bruno@clisp.org>
++<<<<<<< Updated upstream:ChangeLog
+ * tests/test-getaddrinfo.c (AF_UNSPEC): Provide a fallback definition.
+ Needed on BeOS.
++=======
+ * Some other changes.
++>>>>>>> Stashed changes:ChangeLog
2007-09-30 Bruno Haible <bruno@clisp.org>
As you can see from the output of the script's line 2, it was called with
just one argument. This is not enough information for producing output
in a different way than the built-in way - defeating the purpose of
GIT_EXTERNAL_DIFF.
Can the GIT_EXTERNAL_DIFF invocation be done with 7 or more arguments?
It'd be OK to extend the calling convention.
Bruno
[-- Attachment #2: my-diff-for-git --]
[-- Type: application/x-shellscript, Size: 981 bytes --]
^ permalink raw reply
* [NEWS] git adapter included in upcoming Capistrano 2.1
From: Geoffrey Grosenbach @ 2007-09-30 19:13 UTC (permalink / raw)
To: git
I just received news that a git adapter will be included in the next
release of the Ruby-based Capistrano webapp deployment system.
http://dev.rubyonrails.org/ticket/9635
http://capify.org/
I'm using the patch right now and it works well. If you use
Capistrano, you now have one more reason to switch to git!
--
Geoffrey Grosenbach
http://peepcode.com
^ permalink raw reply
* suggestion for git stash
From: Bruno Haible @ 2007-09-30 18:50 UTC (permalink / raw)
To: git
Hi,
"git stash" has the effect of losing the distinction between untracked
changes and changes in the index.
To reproduce:
- Clone the gnulib repository or of any repository with at least 2 files.
- Make changes to two files, say, README and NEWS.
$ git add README
- $ git status
now reports:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: README
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: NEWS
#
- $ git stash
- $ git stash apply
- $ git status
now reports:
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: NEWS
# modified: README
#
no changes added to commit (use "git add" and/or "git commit -a")
Could "git stash" be changed to memorize which changes were already
scheduled for commit and which didn't?
Bruno
^ permalink raw reply
* [PATCH] Support tags in uncommit - use git_id instead of rev_parse
From: Pavel Roskin @ 2007-09-30 17:26 UTC (permalink / raw)
To: Catalin Marinas, git
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
stgit/commands/uncommit.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
index 0cd0fb0..c22d3ea 100644
--- a/stgit/commands/uncommit.py
+++ b/stgit/commands/uncommit.py
@@ -65,7 +65,7 @@ def func(parser, options, args):
if len(args) != 0:
parser.error('cannot specify patch name with --to')
patch_nr = patchnames = None
- to_commit = git.rev_parse(options.to)
+ to_commit = git_id(options.to)
elif options.number:
if options.number <= 0:
parser.error('invalid value passed to --number')
^ permalink raw reply related
* [PATCH] rebase: add --signoff option
From: Steffen Prohaska @ 2007-09-30 16:15 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
When preparing a series of commits for upstream you may
need to signoff commits if you forgot to do so earlier.
This patch teaches git-rebase to signoff during rebase
if you pass the option --signoff.
Notes
1) --signoff cannot be used simultaneously with --interactive.
2) --signoff forces a rebase even if current path is a
descendant of <upstream>.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-rebase.txt | 9 +++++++--
git-rebase--interactive.sh | 3 +++
git-rebase.sh | 10 ++++++++--
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index e8e7579..befe337 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -8,8 +8,8 @@ git-rebase - Forward-port local commits to the updated upstream head
SYNOPSIS
--------
[verse]
-'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
- [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
+'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge] [-C<n>]
+ [--signoff] [ --whitespace=<option>] [-p | --preserve-merges]
[--onto <newbase>] <upstream> [<branch>]
'git-rebase' --continue | --skip | --abort
@@ -201,6 +201,11 @@ OPTIONS
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise). This implies --merge.
+--signoff::
+ Add `Signed-off-by:` line to each commit message, using
+ the committer identity of yourself.
+
+
-v, \--verbose::
Display a diffstat of what changed upstream since the last rebase.
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 8568a4f..29cef17 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -395,6 +395,9 @@ do
-C*)
die "Interactive rebase uses merge, so $1 does not make sense"
;;
+ --si|--sig|--sign|--signo|--signof|--signoff)
+ die "Interactive rebase doesn't support simultaneous signoff."
+ ;;
-v|--verbose)
VERBOSE=t
;;
diff --git a/git-rebase.sh b/git-rebase.sh
index 1583402..3b06bf4 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -46,6 +46,7 @@ dotest=$GIT_DIR/.dotest-merge
prec=4
verbose=
git_am_opt=
+opt_signoff=
continue_merge () {
test -n "$prev_head" || die "prev_head must be defined"
@@ -200,7 +201,7 @@ do
;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
- -s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
+ -s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
case "$#,$1" in
*,*=*)
strategy=`expr "z$1" : 'z-[^=]*=\(.*\)'` ;;
@@ -221,6 +222,10 @@ do
-C*)
git_am_opt="$git_am_opt $1"
;;
+ --si|--sig|--sign|--signo|--signof|--signoff)
+ git_am_opt="$git_am_opt --signoff"
+ opt_signoff=t
+ ;;
-*)
usage
;;
@@ -302,8 +307,9 @@ branch=$(git rev-parse --verify "${branch_name}^0") || exit
# Check if we are already based on $onto with linear history,
# but this should be done only when upstream and onto are the same.
+# The check must also be skipped if signoff is requested.
mb=$(git merge-base "$onto" "$branch")
-if test "$upstream" = "$onto" && test "$mb" = "$onto" &&
+if test "$upstream" = "$onto" && test "$mb" = "$onto" && test -z "$opt_signoff" &&
# linear history?
! git rev-list --parents "$onto".."$branch" | grep " .* " > /dev/null
then
--
1.5.3.3.127.g40d17
^ permalink raw reply related
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Wincent Colaiuta @ 2007-09-30 14:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, Carl Worth, git
In-Reply-To: <20070930134937.GG22560@artemis.corp>
El 30/9/2007, a las 15:49, Pierre Habouzit escribió:
> On Sun, Sep 30, 2007 at 12:45:34PM +0000, Wincent Colaiuta wrote:
>>
>> I think that most people just want to know, "Did it work or not?"
>> and so
>> when the commands chatter too much they go into filter mode, don't
>> really
>> read the output, let alone try to understand it, and just skim it.
>> Ideally Git would be much less "chattery" in general when things
>> work,
>> and only be more verbose when things go wrong; of course, finding
>> that
>> balance point is where the art lies.
>
> That's true for git merge that is fast. But people also want to know
> the command is not stuck in an infinite loop, and for that progress
> bars
> or little \|/- animation.
Yes, I agree. I probably should have said that they either want to
know "*Did* it work?" for near-instant operations (most Git
operations, hopefully), and "*Is* it working?" for long-running ones
(network ops, for example) and in those cases you're right that a
progress bar would be a nice enhancement.
Cheers,
Wincent
^ permalink raw reply
* Re: git-svn merge helper
From: Benoit SIGOURE @ 2007-09-30 14:15 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20070930110550.GA4557@atjola.homenet>
[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]
On Sep 30, 2007, at 1:05 PM, Björn Steinbrink wrote:
> Hi,
>
> I recently discovered git-svn and absolutey love it. One thing that
> I'm
> missing though, is an equivalent of "svn merge" for merging between
> svn
> remotes, to support the SVN way of using "squashed" merges, where you
> just note the merge meta-data in the commit message. "git merge"
> didn't
> work for me (and probably isn't expected to work) to merge between two
> svn branches, so I've resorted to cherry-picking the required commits
> one by one into a temporary branch and then squashing them together by
> doing a --squash merge with a second temporary branch (as in [1]).
I fail to see why you'd want to reproduce the broken behavior of svn
merge. Anyways, git-svn is a great way to merge SVN branches,
unfortunately it can't detect when merges happened on the SVN side.
I think you can use it nevertheless by manually adding a graft at the
last merge point, which would help you merging the right revisions
without having to specify what needs to be merged (unless someone
made another merge on the SVN side, in which case you need to update
your graft).
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Obliterating a commit
From: Wincent Colaiuta @ 2007-09-30 14:13 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: Git Mailing List
In-Reply-To: <1f6632e50709300515h57f4b4ffh9a18fef29b134f13@mail.gmail.com>
El 30/9/2007, a las 14:15, Matthias Kestenholz escribió:
> If you use ssh to push your changes (that is, you are not copying
> or rsyncing packfiles), only commits, trees and blobs, which are
> reachable
> through the DAG will be published. Commits and Blobs which are only
> reachable through your reflog are not published, since the reflog
> only applies
> to your local repository.
Ah, this is good to know. Yes, I do principally publish by pushing to
a central repo, but I wanted to really destroy the objects just in
case in the future I or somebody else ever clones my local repo.
> The simplest thing you could do is remove the reflog for HEAD and
> refs/heads/master respectively your current branch and run 'git prune'
> afterwards (if you have not repacked
> already, otherwise you'd need to run 'git repack -a -d' or 'git gc'
> to get
> rid of blobs inside your packfile.
Thanks very much, Matthias. Blowing away those reflogs and running
git-prune worked and it's doesn't require too much fiddling.
Cheers,
Wincent
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Pierre Habouzit @ 2007-09-30 13:49 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Shawn O. Pearce, Carl Worth, git
In-Reply-To: <912CB4AE-83B9-42D7-A591-E721D1E22439@wincent.com>
[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]
On Sun, Sep 30, 2007 at 12:45:34PM +0000, Wincent Colaiuta wrote:
> El 29/9/2007, a las 11:01, Pierre Habouzit escribió:
>
> > Many git commands output are still messy and indeed, having them in C
> >should help in that regard. The usual culprit are I think:
> >
> > * git fetch/clone/pull/.. ;
> > * git push ;
> > * git repack/gc/... ;
> > * git merge (even with the merge.verbosity set to the minimum it's
> > still not very readable and confusing).
> >
> >
> > I do believe that the quite verbose output git commands sometimes have
> >is quite confusing, and let the user think it's messy. I believe that
> >porcelains should be more silent, it's OK for the plumbing to spit
> >progress messages and so on, because people using the plumbing are able
> >to understand those, but porcelains should not.
>
> I think that most people just want to know, "Did it work or not?" and so
> when the commands chatter too much they go into filter mode, don't really
> read the output, let alone try to understand it, and just skim it.
> Ideally Git would be much less "chattery" in general when things work,
> and only be more verbose when things go wrong; of course, finding that
> balance point is where the art lies.
That's true for git merge that is fast. But people also want to know
the command is not stuck in an infinite loop, and for that progress bars
or little \|/- animation.
--
·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: A tour of git: the basics (and notes on some unfriendly messages)
From: Steffen Prohaska @ 2007-09-30 13:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Git Mailing List, Carl Worth, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0709301343000.28395@racer.site>
On Sep 30, 2007, at 2:44 PM, Johannes Schindelin wrote:
>>
>> A much simpler output could be easier to scan by a human
>>
>> updating 'refs/heads/master' .. fast forward .. ok.
>> updating 'refs/heads/pu' .. forced non-fast forward .. ok.
>> updating 'refs/heads/next' ..
>> ERROR: 'refs/heads/next' not updating to non-fast forward
>> exit(1) here.
>
> No, please no. This is way too short.
>
> If at all, please let 8c3275abcacb83ea3f4c4f4ceb2376799fc282bd be an
> example, and make git respect several different output levels, but not
> changing the default (at first).
good idea.
Steffen
^ permalink raw reply
* Re: Stashing untracked files
From: Wincent Colaiuta @ 2007-09-30 13:18 UTC (permalink / raw)
To: Neil Macneale; +Cc: git, Johannes Schindelin
In-Reply-To: <46FF1F1E.2050000@theory.org>
El 30/9/2007, a las 5:59, Neil Macneale escribió:
> $ git stash -u # stash everything, even untracked files. I never
> # suggesting modifying the default behavior.
Provided it's not the default behaviour, and provided that it doesn't
add ignored files, this sounds perfectly reasonable and potentially
quite useful.
I say *potentially* only because I've yet to find a situation wherein
I can't just do the following:
<hack> # lots of untracked files floating around
$ git stash # untracked files stay exactly where they were
<orthogonal hacking> # untracked files still there
$ git stash apply # still there...
<hack> # still there...
If the content of the untracked files is both, (a) important and (b)
being modified over time, then perhaps it should be being tracked.
Wincent
^ permalink raw reply
* Re: [PATCH v3 2/2] fetch/push: readd rsync support
From: Johannes Schindelin @ 2007-09-30 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: spearce, Daniel Barkalow, git
In-Reply-To: <7vhclciszz.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 29 Sep 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > We lost rsync support when transitioning from shell to C. Support it
> > again (even if the transport is technically deprecated, some people just
> > do not have any chance to use anything else).
>
> s/chance/choice/?
Hehe. I did mean it like that, but feel free to edit!
> > +test "$TEST_RSYNC" && {
>
> Somehow this feels dirty ... perhaps leave early like:
>
> if test -z "$TEST_RSYNC"
> then
> test_expect_success 'skipping rsync transport tests' :
> test_done
> exit
> fi
Okay.
> > diff --git a/transport.c b/transport.c
> > index 4f9cddc..a2ee8f3 100644
> > --- a/transport.c
> > +++ b/transport.c
> > @@ -6,6 +6,330 @@
> > ...
> > +{
> > + struct strbuf buf = STRBUF_INIT, temp_dir = STRBUF_INIT;
> > + struct ref dummy, *tail = &dummy;
> > + struct child_process rsync;
> > + const char *args[5];
> > + int temp_dir_len;
> > +
> > + /* copy the refs to the temporary directory */
> > +
> > + strbuf_addstr(&temp_dir, git_path("rsync-refs-XXXXXX"));
> > + if (!mkdtemp(temp_dir.buf))
> > + die ("Could not make temporary directory");
>
> I wonder how portable mkdtemp() is (it does not seem to be POSIX);
> would we need something in compat/ perhaps based on tempnam()?
My man page said BSD, so I did not bother any more...
Besides, using "tmpnam()" makes gcc say that it is dangerous, and I should
use mkstemp() instead...
> > +static int fetch_objs_via_rsync(struct transport *transport,
> > + int nr_objs, struct ref **to_fetch)
> > +{
> > + struct strbuf buf = STRBUF_INIT;
> > + struct child_process rsync;
> > + const char *args[8];
> > + int result;
> > +
> > + strbuf_addstr(&buf, transport->url);
> > + strbuf_addstr(&buf, "/objects/");
> > +
> > + memset(&rsync, 0, sizeof(rsync));
> > + rsync.argv = args;
> > + rsync.stdout_to_stderr = 1;
> > + args[0] = "rsync";
> > + args[1] = transport->verbose ? "-rv" : "-r";
> > + args[2] = "--ignore-existing";
> > + args[3] = "--exclude";
> > + args[4] = "info";
> > + args[5] = buf.buf;
> > + args[6] = get_object_directory();
> > + args[7] = NULL;
>
> Hmm, we used to do "rsync $remote/objects/ $our/.git/objects/", but this
> omits the trailing "/" from our side. I suspect the reason was to deal
> with the case where our .git/objects was a symlink to elsewhere (which
> was how you did alternates before alternates was invented), which may
> not matter anymore these days.
Nevertheless, this was an oversight on my side. Will change to use a
second strbuf for the local objects directory.
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Johannes Schindelin @ 2007-09-30 12:44 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, Git Mailing List, Carl Worth, Shawn O. Pearce
In-Reply-To: <E8851B12-AAA5-4B4D-9F28-C5AB5AEF0E57@zib.de>
Hi,
On Sun, 30 Sep 2007, Steffen Prohaska wrote:
>
> On Sep 30, 2007, at 12:25 AM, Junio C Hamano wrote:
>
> > Steffen Prohaska <prohaska@zib.de> writes:
> >
> > > - git push: prints updates of remote heads. A message about
> > > failing to update a remote head may get lost.
> >
> > Please do not remove the report of successful update, as people often
> > say "git push" or "git push $there" without explicitly saying which
> > refs to push. When pushing out to publish, I say "git push ko" (to
> > mean k.org) and I _want_ my positive feedback.
>
> Yes but it's pretty technical.
>
> A much simpler output could be easier to scan by a human
>
> updating 'refs/heads/master' .. fast forward .. ok.
> updating 'refs/heads/pu' .. forced non-fast forward .. ok.
> updating 'refs/heads/next' ..
> ERROR: 'refs/heads/next' not updating to non-fast forward
> exit(1) here.
No, please no. This is way too short.
If at all, please let 8c3275abcacb83ea3f4c4f4ceb2376799fc282bd be an
example, and make git respect several different output levels, but not
changing the default (at first).
Ciao,
Dscho
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Wincent Colaiuta @ 2007-09-30 12:45 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, Carl Worth, git
In-Reply-To: <20070929090121.GA4216@artemis.corp>
El 29/9/2007, a las 11:01, Pierre Habouzit escribió:
> Many git commands output are still messy and indeed, having them
> in C
> should help in that regard. The usual culprit are I think:
>
> * git fetch/clone/pull/.. ;
> * git push ;
> * git repack/gc/... ;
> * git merge (even with the merge.verbosity set to the minimum it's
> still not very readable and confusing).
>
>
> I do believe that the quite verbose output git commands sometimes
> have
> is quite confusing, and let the user think it's messy. I believe that
> porcelains should be more silent, it's OK for the plumbing to spit
> progress messages and so on, because people using the plumbing are
> able
> to understand those, but porcelains should not.
I think that most people just want to know, "Did it work or not?" and
so when the commands chatter too much they go into filter mode, don't
really read the output, let alone try to understand it, and just skim
it. Ideally Git would be much less "chattery" in general when things
work, and only be more verbose when things go wrong; of course,
finding that balance point is where the art lies.
Wincent
^ permalink raw reply
* Re: Obliterating a commit
From: Matthias Kestenholz @ 2007-09-30 12:15 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <D2BD14BD-44F2-4D01-AAEE-6CBC2A2DE85B@wincent.com>
Hello,
2007/9/30, Wincent Colaiuta <win@wincent.com>:
> A couple of days ago I mistakenly checked in a file that had some
> confidential information in it. I immediately realized and amended my
> commit, and this is a local repository whose contents won't be
> visible until I push them out.
>
> So how do I *really* get rid of the that commit before publishing? I
> couldn't find any porcelain or plumbing to do this. Do I have to
> manually destroy it? ie. wind back the HEAD, manually remove the
> commit object, the corresponding tree object, the corresponding file
> blobs, and probably manually remove the entry from the reflog as well?
>
If you use ssh to push your changes (that is, you are not copying
or rsyncing packfiles), only commits, trees and blobs, which are reachable
through the DAG will be published. Commits and Blobs which are only
reachable through your reflog are not published, since the reflog only applies
to your local repository.
The simplest thing you could do is remove the reflog for HEAD and
refs/heads/master respectively your current branch and run 'git prune'
afterwards (if you have not repacked
already, otherwise you'd need to run 'git repack -a -d' or 'git gc' to get
rid of blobs inside your packfile.
> Is there a "shortcut" wherein I can somehow mark this commit and its
> related tree and file blobs as unreachable, and then use git-prune to
> erradicate them?
>
You don't need to mark anything -- it's sufficient that the blob with the
confidential information is only reachable through the reflog (which you
need to remove, obviously, if you want to get rid of the blob locally too)
Cheers,
Matthias
^ permalink raw reply
* Obliterating a commit
From: Wincent Colaiuta @ 2007-09-30 11:32 UTC (permalink / raw)
To: Git Mailing List
A couple of days ago I mistakenly checked in a file that had some
confidential information in it. I immediately realized and amended my
commit, and this is a local repository whose contents won't be
visible until I push them out.
So how do I *really* get rid of the that commit before publishing? I
couldn't find any porcelain or plumbing to do this. Do I have to
manually destroy it? ie. wind back the HEAD, manually remove the
commit object, the corresponding tree object, the corresponding file
blobs, and probably manually remove the entry from the reflog as well?
Is there a "shortcut" wherein I can somehow mark this commit and its
related tree and file blobs as unreachable, and then use git-prune to
erradicate them?
Cheers,
Wincent
^ permalink raw reply
* git-svn merge helper
From: Björn Steinbrink @ 2007-09-30 11:05 UTC (permalink / raw)
To: git
Hi,
I recently discovered git-svn and absolutey love it. One thing that I'm
missing though, is an equivalent of "svn merge" for merging between svn
remotes, to support the SVN way of using "squashed" merges, where you
just note the merge meta-data in the commit message. "git merge" didn't
work for me (and probably isn't expected to work) to merge between two
svn branches, so I've resorted to cherry-picking the required commits
one by one into a temporary branch and then squashing them together by
doing a --squash merge with a second temporary branch (as in [1]).
Of course that becomes extremely annoying if there are like 200
commits to merge, so I came up with the following script to help me.
It does just what I described above, but automated. Usage is like this:
git-svn-merge trunk 123 543
Which does the same as "svn merge -r123:543 trunk-url", except for being
incremental (ie. no huge one-time patch, eventually causing a massive
set of conflicts) and often faster.
In case of conflicts, it bails out and let's you fix them. Then you can
just re-run it with the same parameters again, as it automatically
determines where to start cherry-picking if you're currently on the
merge branch.
It's neither complete nor nice to look at, but it more or less gets the
job done, so I thought I'll just post it here, maybe someone picks it up
and brings it into shape.
Thanks,
Björn
[1] http://cheat.errtheblog.com/s/gitsvn/
#!/bin/sh
BRANCH=$(git branch | grep \* | cut -d ' ' -f2)
START=$(git svn find-rev r$2 $1)
END=$(git svn find-rev r$3 $1)
if echo $BRANCH | grep -q svnmerge/
then
START=$(git svn find-rev r$(git svn find-rev HEAD) $1)
else
git checkout -b svnmerge/$BRANCH
fi
for HASH in $(git log --pretty=format:%H --reverse $START..$END)
do
git cherry-pick $HASH || exit
done
git checkout $BRANCH
git checkout -b svnmerge/$BRANCH-squashed
git merge --squash svnmerge/$BRANCH
git commit -m "Merged changes from revisions $2-$3 from $1 into $BRANCH."
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Junio C Hamano @ 2007-09-30 10:17 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List, Carl Worth, Shawn O. Pearce
In-Reply-To: <E8851B12-AAA5-4B4D-9F28-C5AB5AEF0E57@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> ... If everything's ok I do.
>
> git checkout master
> git merge for/master
> git push
>
> The last merge must be a fast forward.
Last week I saw somebody (I think it was Shawn) mentioned a
trick:
git push . thisbranch:thatbranch
will moves thatbranch to thisbranch iff thisbranch is a
descendant of thatbranch. So doing
git push . for-master:master
instead of that checkout + merge command sequence would
obviously be a good solution for your particular use case.
Having said that it may make sense to swap the order so that the
diffstat is shown first and then a single line "Merge made by
recursive" or "Updatting A..B, Fast Forward" concludes the
report. At least, I do not think such a swapping would hurt the
usability, although people used to the UI may first feel uneasy.
I would not object to such a patch in principle.
^ permalink raw reply
* Re: [PATCH] prune, rm, show remote: exit with error code 1 on failure
From: Junio C Hamano @ 2007-09-30 9:54 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <641soeuv.fsf@blue.sea.net>
Thanks.
Because this is a bugfix patch, we would want the fix applied to
'maint' to become part of 1.5.3.4, but your patch contained the
fix for "remote rm" that is not (and will not be) part of 'maint'.
I split the patch into two, applied the bits without "rm" part
to 'maint', merged the result into 'master' and applied the fix
for "rm" on 'master'.
^ permalink raw reply
* Re: Stashing untracked files
From: Steffen Prohaska @ 2007-09-30 8:41 UTC (permalink / raw)
To: Neil Macneale; +Cc: git, Johannes Schindelin
In-Reply-To: <46FF1F1E.2050000@theory.org>
On Sep 30, 2007, at 5:59 AM, Neil Macneale wrote:
> git stash is an acknowledgment that not everything needs to be
> committed, and sometimes working source trees are messy. Prior to
> the stash command, I just accepted that I'd need to commit
> everything and do some maintenance to un-commit those changes.
> stash is awesome for me and the realities of the way I need to
> work. IMHO, it would be the best thing since sliced bread if it
> handled untracked files.
I agree, it could be a great tool. Even only to make me feel better
before running 'git clean' on a larger source tree when I was to
lazy to scan 'git clean -n' in detail.
BTW, I don't have results of the builds in my work tree but keep
them in a separate directory. Nearly everything in the work tree
is 'real' source code, maybe cluttered with some backups or tmp files.
> If this is really just a problem for me, I can write a shell script
> to do the dirty work. I just wonder if it is a common enough use
> case that it merits support in the tool itself.
I think it would be useful. Here is a problem I ran into last week:
A merge failed because it wanted to add a file not tracked by
the current branch. At first I didn't fully appreciate this fact
and thought that 'git stash' could help. But to do so, it would
need to store the _untracked_ file and remove it from the work tree.
This would allow the merge to succeed. Current stash didn't really
help.
Steffen
^ permalink raw reply
* Re: [PATCH] WinGit: include html pages from official git.git's html branch
From: Steffen Prohaska @ 2007-09-30 8:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709300022080.28395@racer.site>
On Sep 30, 2007, at 1:23 AM, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 29 Sep 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Sat, 29 Sep 2007, Steffen Prohaska wrote:
>>>
>>>> It is assumed that a matching version of the html documentation is
>>>> available as the HEAD of /doc/git/html/.git. If not an error
>>>> will be
>>>> reported.
>>>>
>>>> This patch doesn't include a mechanism to fetch the html pages to
>>>> /doc/git/html/.git. You should manually clone them. Maybe this
>>>> could
>>>> handled as a submodule of msysgit?
>>>
>>> I'd rather handle it as in git.git, as another branch, and not check
>>> it out in /git/html/, but rather use "git read-tree
>>> --prefix=/tmp/WinGit/share/git/html origin/html", or some such.
>>
>> This is starting to smell like an opportunity to use the gitlink
>> stuff,
>> isn't it?
>
> I'd agree that we could have a submodule in /doc/git/html/. This way,
> even users of msysGit and GitMe would benefit.
And we could completely tag a WinGit release. The version of the
html docs included would be defined by the submodule's head in
/doc/git/html. This is what I had in mind when submitting the
patch. Maybe I didn't express this clearly.
I do not yet understand submodules sufficiently. Therefore I didn't
add a patch that actually sets up the submodule in /doc/git/html.
Maybe I'll do so later today.
Steffen
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Steffen Prohaska @ 2007-09-30 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Carl Worth, Shawn O. Pearce
In-Reply-To: <7vlkapjeir.fsf@gitster.siamese.dyndns.org>
On Sep 30, 2007, at 12:25 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> - git push: prints updates of remote heads. A message about
>> failing to update a remote head may get lost.
>
> Please do not remove the report of successful update, as people
> often say "git push" or "git push $there" without explicitly
> saying which refs to push. When pushing out to publish, I say
> "git push ko" (to mean k.org) and I _want_ my positive feedback.
Yes but it's pretty technical.
A much simpler output could be easier to scan by a human
updating 'refs/heads/master' .. fast forward .. ok.
updating 'refs/heads/pu' .. forced non-fast forward .. ok.
updating 'refs/heads/next' ..
ERROR: 'refs/heads/next' not updating to non-fast forward
exit(1) here.
If we exit after the very first problem it can't get lost.
After fixing the issue you can just 'git push' again.
>> - git merge: the fact that a merge is a fast forward merge gets
>> printed at the very top, followed by (often a lot of) diffstat.
>> I know diffstat can help to judge if the merge did what you
>> expected. But even more important is the fact that the merge
>> was just a fast forward, which may get buried under lots of output.
>
> I do not think fast-forwardness is particularly interesting. If
> you find fast-forwardness interesting, I suspect you would even
> want to know what _your_ change that were not in the other side
> of the merge, which is something that we do not even report
> right now.
I use it to advance a branch to a temporary integration branch.
At that point I expect that the merge is a fast forward. Here's
what I do.
git checkout -b for/master master
git merge branch-with-good-topics
git branch -f scratch
git push compileservers # pushes scratch for automatic builds
Now I wait for compiles to finish. Typically I continue not before
the next morning. If everything's ok I do.
git checkout master
git merge for/master
git push
The last merge must be a fast forward. This is the only fact I'm
interested in. I could do 'git reset' or 'git branch -f' but then
I'd loose the check if it's a fast forward.
I don't merge directly to master to avoid any accidentally push.
I can also easily revert by just deleting 'for/master'.
Maybe there's a better workflow?
>> Maybe git should become more quiet, as other unix tools are, and
>> per default only report problems. Technical details and progress
>> could be requested explicitly by '--verbose' or similar.
>
> I'd agree with this sentiment in principle, and many of the
> things you propose to remove above fall into the "unnecessary
> clutter" category. But some of the existing output fall into
> the "necessary info" category --- diffstart after merge
I agree. Could we print the note about fast forward _after_ the
diffstat? Maybe there are more useful oneline information that
could be output there.
> and report of successful remote ref updates are such things, so we
> should be careful not to go overboard.
But the output could be less technical and more human readable.
Also diffstat's output and "git push" are different. diffstats
change with the content of your repo. "git push" just succeeds
or fails. If is succeeds it updates remote refs according to your
configuration. There is no new information in the output beyond
success or failure [which is not quite true if you depend on
git push finding matching refs automatically -- I don't]. I don't
think the sha1's printed are needed by anyone. And if someone
needs them, he could call push with '--verbose'.
I asked about a '--dry-run' switch to "git push" some time ago,
which would only report what "git push" would do without actually
changing anything on the remote side. I'd use this to check what
I expect to do. Just in case I messed up my configuration. At the
time "git push" is actually pushing it's too late to fix a broken
configuration. I know '--dry-run' it's not trivial to implement
and I'll likely have no time to look into it.
Steffen
^ permalink raw reply
* [ANNOUNCE] qgit-2.0
From: Marco Costalba @ 2007-09-30 7:13 UTC (permalink / raw)
To: Git, linux-kernel
This is the final qgit-2.0
With qgit you will be able to browse revision histories, view patch content
and changed files, graphically following different development branches.
IMPORTANT NOTE
git 1.5.3 or better is required, Qt 4.3 or better is required.
FEATURES
- View revisions, diffs, files history, files annotation, archive tree.
- Commit changes visually cherry picking modified files.
- Apply or format patch series from selected commits, drag and
drop commits between two instances of qgit.
- Associate commands sequences, scripts and anything else executable
to a custom action. Actions can be run from menu and corresponding
output is grabbed by a terminal window.
- qgit implements a GUI for the most common StGIT commands like push/pop
and apply/format patches. You can also create new patches or refresh
current top one using the same semantics of git commit, i.e. cherry
picking single modified files.
NEW IN THIS RELEASE
This is the final public release of the shining new qgit 2.0 based on
the shining new Qt 4.3 libraries.
All the features of the stable series have been ported. In addition this
new release sports a better GUI both on visually side and on usability side.
Annotation code is much improved in speed and in power, as example
now follows file renames, try it on any git tree file to see a real example.
A new and much improved repository browsing experience is now possible,
in particular you don't need to switch to patch tab to view diff
content anymore. Patch information, together with patch description,
is shown in bottom left pane.
Finally, qgit works natively under Windows due to Qt 4.3 libraries.
The detailed list of changes is very long and interested people can
read from public qgit repository.
Although there are a lot of new features code is considered stable due
to have been very long in 'rc' state.
You can download the tarball from
http://sourceforge.net/projects/qgit
or clone the public git repository at
git://git.kernel.org/pub/scm/qgit/qgit4.git
Please, check the shipped README for detailed build and install information.
Have fun
Marco
^ 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