squash commits deep down in history
Hi, i need to squash several commits into a single one in a automated way. I know that there is interactive rebase, which can also be automated using GIT_SEQUENCE_EDITOR. Unfortunately my history is very large and i need to squash deep down in the history several times. So using interactive rebase seems not to be the right tool. I wonder if i can solve this task using filter-branch? I have a file that list the SHA1s for each squash operation per line. All SHA1s of a line are in chronological order (youngest to oldest), or in other words: the first SHA1 is the child of the second, and so on. | ab4423e 3432343 3234252 | 2324342 5232343 | ... Lets say there are N lines in that file. Each line means: squash all SHA1s of this line into the first (or last) SHA1 of this line. Performing this task with rebase would require N rewritings of the history. So e.g. HEAD (but many others too) would be rewritten N times even if it is not directly part of a line. My thinking is, that a filter-branch can do this in a single rewrite and therefore would be much more performant. How can i solve this? Any ideas? Best regards Henning -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] git-gui: improve gui.maxfilesdisplayed popup message
Signed-off-by: Csaba Kiraly kir...@disi.unitn.it
---
git-gui.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-gui.sh b/git-gui.sh
index f86a948..211f57f 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1977,7 +1977,7 @@ proc display_all_files {} {
if {!$files_warning} {
# do not repeatedly warn:
set files_warning 1
- info_popup [mc Displaying only %s of %s
files. \
+ info_popup [mc Display limit
(gui.maxfilesdisplayed = %s) reached, not showing all %s files. \
$display_limit [llength $to_display]]
}
continue
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] git-gui: fix problem with important files not shown if, gui.maxfilesdisplayed is exceeded
gui.maxfilesdisplayed (added in dd6451f9c7c5a36d3006231b618ac6da06c7c7b4)
was applied brute force on the file list in alphabetic order. As a result,
files that had modifications might not be displayed by git-gui. Even
worse, files that are already in the index might not be displayed, which
makes git-gui unusable.
This fix changes the meaning of gui.maxfilesdisplayed, making it a soft
limit that only applies to _O files, i.e. files that are Untracked,
not staged.
Signed-off-by: Csaba Kiraly kir...@disi.unitn.it
---
git-gui.sh | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index bf68699..f86a948 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1967,20 +1967,22 @@ proc display_all_files {} {
set to_display [lsort [array names file_states]]
set display_limit [get_config gui.maxfilesdisplayed]
-if {[llength $to_display] $display_limit} {
-if {!$files_warning} {
-# do not repeatedly warn:
-set files_warning 1
-info_popup [mc Displaying only %s of %s files. \
-$display_limit [llength $to_display]]
-}
-set to_display [lrange $to_display 0 [expr {$display_limit-1}]]
-}
+set displayed 0
foreach path $to_display {
set s $file_states($path)
set m [lindex $s 0]
set icon_name [lindex $s 1]
+if {$displayed $display_limit [string index $m 1] eq {O} } {
+if {!$files_warning} {
+# do not repeatedly warn:
+set files_warning 1
+info_popup [mc Displaying only %s of %s files. \
+$display_limit [llength $to_display]]
+}
+continue
+}
+
set s [string index $m 0]
if {$s ne {U} $s ne {_}} {
display_all_files_helper $ui_index $path \
@@ -1995,6 +1997,7 @@ proc display_all_files {} {
if {$s ne {_}} {
display_all_files_helper $ui_workdir $path \
$icon_name $s
+incr displayed
}
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plumbing version of 'git branch --contains' ?
On Wed, Oct 22, 2014 at 08:19:07PM +, Crabtree, Andrew wrote:
I need to get a list of refs that can reach a certain SHA in in a script.
git branch --contains SHA
would be great (runs in ~2 seconds), but not my preferred option for
scripting.
I tried
for br in $(git for-each-ref --format='%(refname:short)' refs/heads/)
do
git merge-base --is-ancestor $1 ${br}
if [ $? -eq 0 ]
then
echo ${br}
fi
done
Which gives me perfect output, but takes 82 seconds to run in my environment.
Right. There's some setup work that happens in `git branch --contains`
that we end up repeating.
Is there an alternative I'm missing to give me the run time
performance of 'git branch --contains' but with stable output suitable
for parsing?
Sadly, no, there isn't currently. The right tool would be `git
for-each-ref --contains`, but it doesn't exist yet. I was working
towards it, but got stopped on factoring out a `--contains` traversal
suitable for both `git tag` and `git branch` (they currently are
different and make performance tradeoffs based on the expected depth of
the merge bases, which is usually different between tags and
branches)[1]. That's work I'd love to resume, but I haven't gotten
around to it yet.
-Peff
[1] http://thread.gmane.org/gmane.comp.version-control.git/252472
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] refs.c make ref_transaction_create a wrapper to ref_transaction_update
Ronnie Sahlberg sahlb...@google.com writes:
Subject: Re: [PATCH 01/15] refs.c make ref_transaction_create a wrapper to
ref_transaction_update
Missing colon after refs.c
commit 03001144a015f81db5252005841bb78f57d62774 upstream.
Huh?
The ref_transaction_update function can already be used to create refs by
passing null_sha1 as the old_sha1 parameter. Simplify by replacing
transaction_create with a thin wrapper.
Nice code reduction.
Change-Id: I687dd47cc4f4e06766e8313b4fd1b07cd4a56c1a
Please don't leak local housekeeping details into the official
history.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
refs.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/refs.c b/refs.c
index 0368ed4..ed0485e 100644
--- a/refs.c
+++ b/refs.c
@@ -3623,31 +3623,8 @@ int ref_transaction_create(struct ref_transaction
*transaction,
int flags, const char *msg,
struct strbuf *err)
{
- struct ref_update *update;
-
- assert(err);
-
- if (transaction-state != REF_TRANSACTION_OPEN)
- die(BUG: create called for transaction that is not open);
-
- if (!new_sha1 || is_null_sha1(new_sha1))
- die(BUG: create ref with null new_sha1);
-
- if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
- strbuf_addf(err, refusing to create ref with bad name %s,
- refname);
- return -1;
- }
-
- update = add_update(transaction, refname);
-
- hashcpy(update-new_sha1, new_sha1);
- hashclr(update-old_sha1);
- update-flags = flags;
- update-have_old = 1;
- if (msg)
- update-msg = xstrdup(msg);
- return 0;
+ return ref_transaction_update(transaction, refname, new_sha1,
+ null_sha1, flags, 1, msg, err);
}
int ref_transaction_delete(struct ref_transaction *transaction,
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/15] refs.c: make ref_transaction_delete a wrapper for ref_transaction_update
Ronnie Sahlberg sahlb...@google.com writes:
commit 0beeda259297c92d411ecc92fa508ec7cfd87cc5 upstream.
Change-Id: I685291986e544a8dc14f94c73b6a7c6400acd9d2
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
refs.c | 22 ++
refs.h | 2 +-
2 files changed, 3 insertions(+), 21 deletions(-)
Nice code reduction.
diff --git a/refs.c b/refs.c
index ed0485e..c607ab7 100644
--- a/refs.c
+++ b/refs.c
@@ -3633,26 +3633,8 @@ int ref_transaction_delete(struct ref_transaction
*transaction,
int flags, int have_old, const char *msg,
struct strbuf *err)
{
- struct ref_update *update;
-
- assert(err);
-
- if (transaction-state != REF_TRANSACTION_OPEN)
- die(BUG: delete called for transaction that is not open);
-
- if (have_old !old_sha1)
- die(BUG: have_old is true but old_sha1 is NULL);
-
- update = add_update(transaction, refname);
- update-flags = flags;
- update-have_old = have_old;
- if (have_old) {
- assert(!is_null_sha1(old_sha1));
- hashcpy(update-old_sha1, old_sha1);
- }
- if (msg)
- update-msg = xstrdup(msg);
- return 0;
+ return ref_transaction_update(transaction, refname, null_sha1,
+ old_sha1, flags, have_old, msg, err);
}
int update_ref(const char *action, const char *refname,
diff --git a/refs.h b/refs.h
index 2bc3556..7d675b7 100644
--- a/refs.h
+++ b/refs.h
@@ -283,7 +283,7 @@ struct ref_transaction *ref_transaction_begin(struct
strbuf *err);
/*
* Add a reference update to transaction. new_sha1 is the value that
- * the reference should have after the update, or zeros if it should
+ * the reference should have after the update, or null_sha1 if it should
* be deleted. If have_old is true, then old_sha1 holds the value
* that the reference should have had before the update, or zeros if
* it must not have existed beforehand.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] refs.c make ref_transaction_create a wrapper to ref_transaction_update
On Thu, Oct 23, 2014 at 10:42 AM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
Subject: Re: [PATCH 01/15] refs.c make ref_transaction_create a wrapper to
ref_transaction_update
Missing colon after refs.c
commit 03001144a015f81db5252005841bb78f57d62774 upstream.
Huh?
The ref_transaction_update function can already be used to create refs by
passing null_sha1 as the old_sha1 parameter. Simplify by replacing
transaction_create with a thin wrapper.
Nice code reduction.
Change-Id: I687dd47cc4f4e06766e8313b4fd1b07cd4a56c1a
Please don't leak local housekeeping details into the official
history.
Ah, Ok.
Do you want me to re-send the series with these lines deleted ?
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
refs.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
diff --git a/refs.c b/refs.c
index 0368ed4..ed0485e 100644
--- a/refs.c
+++ b/refs.c
@@ -3623,31 +3623,8 @@ int ref_transaction_create(struct ref_transaction
*transaction,
int flags, const char *msg,
struct strbuf *err)
{
- struct ref_update *update;
-
- assert(err);
-
- if (transaction-state != REF_TRANSACTION_OPEN)
- die(BUG: create called for transaction that is not open);
-
- if (!new_sha1 || is_null_sha1(new_sha1))
- die(BUG: create ref with null new_sha1);
-
- if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL)) {
- strbuf_addf(err, refusing to create ref with bad name %s,
- refname);
- return -1;
- }
-
- update = add_update(transaction, refname);
-
- hashcpy(update-new_sha1, new_sha1);
- hashclr(update-old_sha1);
- update-flags = flags;
- update-have_old = 1;
- if (msg)
- update-msg = xstrdup(msg);
- return 0;
+ return ref_transaction_update(transaction, refname, new_sha1,
+ null_sha1, flags, 1, msg, err);
}
int ref_transaction_delete(struct ref_transaction *transaction,
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/15] refs.c: add a new update_type field to ref_update
Ronnie Sahlberg sahlb...@google.com writes:
commit 1bfd3091a3d95a6268894182117eed823217dd9d upstream.
Add a field that describes what type of update this refers to. For now
the only type is UPDATE_SHA1 but we will soon add more types.
OK, so the idea is that 03/15 and 07/15 that let callers to say
transaction_update_REF or transaction_update_REFLOG are nicety
wrappers and the underlying machinery will use UPDATE_SHA1 (added
here) and UPDATE_LOG (added in 07/15), which I find is a nice
layering.
Going in a good direction.
Change-Id: I9bf76454d1c789877a6aeb360cbb309971c9b5c4
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
refs.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index a1bfaa2..8803b95 100644
--- a/refs.c
+++ b/refs.c
@@ -3504,6 +3504,10 @@ int for_each_reflog(each_ref_fn fn, void *cb_data)
return retval;
}
+enum transaction_update_type {
+ UPDATE_SHA1 = 0
+};
+
/**
* Information needed for a single ref update. Set new_sha1 to the
* new value or to zero to delete the ref. To check the old value
@@ -3511,6 +3515,7 @@ int for_each_reflog(each_ref_fn fn, void *cb_data)
* value or to zero to ensure the ref does not exist before update.
*/
struct ref_update {
+ enum transaction_update_type update_type;
unsigned char new_sha1[20];
unsigned char old_sha1[20];
int flags; /* REF_NODEREF? */
@@ -3571,12 +3576,14 @@ void transaction_free(struct transaction *transaction)
}
static struct ref_update *add_update(struct transaction *transaction,
- const char *refname)
+ const char *refname,
+ enum transaction_update_type update_type)
{
size_t len = strlen(refname);
struct ref_update *update = xcalloc(1, sizeof(*update) + len + 1);
strcpy((char *)update-refname, refname);
+ update-update_type = update_type;
ALLOC_GROW(transaction-updates, transaction-nr + 1,
transaction-alloc);
transaction-updates[transaction-nr++] = update;
return update;
@@ -3606,7 +3613,7 @@ int transaction_update_ref(struct transaction
*transaction,
return -1;
}
- update = add_update(transaction, refname);
+ update = add_update(transaction, refname, UPDATE_SHA1);
hashcpy(update-new_sha1, new_sha1);
update-flags = flags;
update-have_old = have_old;
@@ -3684,13 +3691,17 @@ static int ref_update_reject_duplicates(struct
ref_update **updates, int n,
assert(err);
- for (i = 1; i n; i++)
+ for (i = 1; i n; i++) {
+ if (updates[i - 1]-update_type != UPDATE_SHA1 ||
+ updates[i]-update_type != UPDATE_SHA1)
+ continue;
if (!strcmp(updates[i - 1]-refname, updates[i]-refname)) {
strbuf_addf(err,
Multiple updates for ref '%s' not
allowed.,
updates[i]-refname);
return 1;
}
+ }
return 0;
}
@@ -3722,13 +3733,17 @@ int transaction_commit(struct transaction
*transaction,
goto cleanup;
}
- /* Acquire all locks while verifying old values */
+ /* Acquire all ref locks while verifying old values */
for (i = 0; i n; i++) {
struct ref_update *update = updates[i];
int flags = update-flags;
+ if (update-update_type != UPDATE_SHA1)
+ continue;
+
if (is_null_sha1(update-new_sha1))
flags |= REF_DELETING;
+
update-lock = lock_ref_sha1_basic(update-refname,
(update-have_old ?
update-old_sha1 :
@@ -3750,6 +3765,8 @@ int transaction_commit(struct transaction *transaction,
for (i = 0; i n; i++) {
struct ref_update *update = updates[i];
+ if (update-update_type != UPDATE_SHA1)
+ continue;
if (!is_null_sha1(update-new_sha1)) {
if (write_ref_sha1(update-lock, update-new_sha1,
update-msg)) {
@@ -3767,6 +3784,8 @@ int transaction_commit(struct transaction *transaction,
for (i = 0; i n; i++) {
struct ref_update *update = updates[i];
+ if (update-update_type != UPDATE_SHA1)
+ continue;
if (update-lock) {
if (delete_ref_loose(update-lock, update-type, err)) {
ret = TRANSACTION_GENERIC_ERROR;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Re: [PATCH 06/15] copy.c: make copy_fd preserve meaningful errno
Ronnie Sahlberg sahlb...@google.com writes:
commit 306805ccd147bfdf160b288a8d51fdf9b77ae0fa upstream.
Update copy_fd to return a meaningful errno on failure.
These two are good changes, but makes me wonder if more places
benefit from having error_errno() that does the save away errno,
use strerror(errno) to give an error message and restore errno
for us.
Not meant as a suggestion for further changes in this series, but as
a future discussion item.
Change-Id: I771f9703acc816902affcf35ff2a56d9426315ac
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
copy.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/copy.c b/copy.c
index f2970ec..a8d366e 100644
--- a/copy.c
+++ b/copy.c
@@ -8,12 +8,17 @@ int copy_fd(int ifd, int ofd)
if (!len)
break;
if (len 0) {
- return error(copy-fd: read returned %s,
- strerror(errno));
+ int save_errno = errno;
+ error(copy-fd: read returned %s, strerror(errno));
+ errno = save_errno;
+ return -1;
+ }
+ if (write_in_full(ofd, buffer, len) 0) {
+ int save_errno = errno;
+ error(copy-fd: write returned %s, strerror(errno));
+ errno = save_errno;
+ return -1;
}
- if (write_in_full(ofd, buffer, len) 0)
- return error(copy-fd: write returned %s,
- strerror(errno));
}
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] refs.c make ref_transaction_create a wrapper to ref_transaction_update
Ronnie Sahlberg sahlb...@google.com writes: On Thu, Oct 23, 2014 at 10:42 AM, Junio C Hamano gits...@pobox.com wrote: Ronnie Sahlberg sahlb...@google.com writes: Subject: Re: [PATCH 01/15] refs.c make ref_transaction_create a wrapper to ref_transaction_update Missing colon after refs.c ... Change-Id: I687dd47cc4f4e06766e8313b4fd1b07cd4a56c1a Please don't leak local housekeeping details into the official history. Ah, Ok. Do you want me to re-send the series with these lines deleted ? When the series is rerolled, I'd like to see these crufts gone. But please do not re-send the series without waiting for further reviews and making necessary updates, if any. Otherwise it will only make extra busywork for you and me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/15] copy.c: make copy_fd preserve meaningful errno
On Thu, Oct 23, 2014 at 10:51 AM, Junio C Hamano gits...@pobox.com wrote:
Ronnie Sahlberg sahlb...@google.com writes:
commit 306805ccd147bfdf160b288a8d51fdf9b77ae0fa upstream.
Update copy_fd to return a meaningful errno on failure.
These two are good changes, but makes me wonder if more places
benefit from having error_errno() that does the save away errno,
use strerror(errno) to give an error message and restore errno
for us.
Not meant as a suggestion for further changes in this series, but as
a future discussion item.
That sounds like a good idea.
As a separate series once these are done, I can volunteer to go
through all the errno handling in git
and look into that.
Change-Id: I771f9703acc816902affcf35ff2a56d9426315ac
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
copy.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/copy.c b/copy.c
index f2970ec..a8d366e 100644
--- a/copy.c
+++ b/copy.c
@@ -8,12 +8,17 @@ int copy_fd(int ifd, int ofd)
if (!len)
break;
if (len 0) {
- return error(copy-fd: read returned %s,
- strerror(errno));
+ int save_errno = errno;
+ error(copy-fd: read returned %s, strerror(errno));
+ errno = save_errno;
+ return -1;
+ }
+ if (write_in_full(ofd, buffer, len) 0) {
+ int save_errno = errno;
+ error(copy-fd: write returned %s, strerror(errno));
+ errno = save_errno;
+ return -1;
}
- if (write_in_full(ofd, buffer, len) 0)
- return error(copy-fd: write returned %s,
- strerror(errno));
}
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Plumbing version of 'git branch --contains' ?
Jeff King p...@peff.net writes:
On Wed, Oct 22, 2014 at 08:19:07PM +, Crabtree, Andrew wrote:
I need to get a list of refs that can reach a certain SHA in in a script.
git branch --contains SHA
would be great (runs in ~2 seconds), but not my preferred option for
scripting.
I tried
for br in $(git for-each-ref --format='%(refname:short)' refs/heads/)
do
git merge-base --is-ancestor $1 ${br}
if [ $? -eq 0 ]
then
echo ${br}
fi
done
Which gives me perfect output, but takes 82 seconds to run in my environment.
Right. There's some setup work that happens in `git branch --contains`
that we end up repeating.
Is there an alternative I'm missing to give me the run time
performance of 'git branch --contains' but with stable output suitable
for parsing?
Sadly, no, there isn't currently. The right tool would be `git
for-each-ref --contains`, but it doesn't exist yet. I was working
towards it, but got stopped on factoring out a `--contains` traversal
suitable for both `git tag` and `git branch` (they currently are
different and make performance tradeoffs based on the expected depth of
the merge bases, which is usually different between tags and
branches)[1]. That's work I'd love to resume, but I haven't gotten
around to it yet.
-Peff
[1] http://thread.gmane.org/gmane.comp.version-control.git/252472
Thanks for status update. I was wondering if I should start looking
into it myself.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/15] refs.c: only write reflog update if msg is non-NULL
Ronnie Sahlberg sahlb...@google.com writes:
commit 020ed65a12838bdead64bc3c5de249d3c8f5cfd8 upstream.
When performing a reflog transaction update, only write to the reflog iff
msg is non-NULL. This can then be combined with REFLOG_TRUNCATE to perform
an update that only truncates but does not write.
Does any existing caller call this codepath with update-msg == NULL?
Will please truncate stay to be the only plausible special cause
to call into this codepath without having any meaningful message?
I am trying to make sure that this patch is not painting us into a
corner where we will find out another reason for doing something
esoteric in this codepath but need to find a way other than setting
msg to NULL for the caller to trigger that new codepath. Put it in
another way, please convince me that a new boolean field in update,
e.g. update-truncate_reflog, is way overkill for this.
Change-Id: I44c89caa7e7c4960777b79cfb5d339a5aa3ddf7a
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
refs.c | 5 +++--
refs.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index d54c3b9..f14b76e 100644
--- a/refs.c
+++ b/refs.c
@@ -3895,8 +3895,9 @@ int transaction_commit(struct transaction *transaction,
update-reflog_fd = -1;
continue;
}
- if (log_ref_write_fd(update-reflog_fd, update-old_sha1,
- update-new_sha1,
+ if (update-msg
+ log_ref_write_fd(update-reflog_fd,
+ update-old_sha1, update-new_sha1,
update-committer, update-msg)) {
error(Could write to reflog: %s. %s,
update-refname, strerror(errno));
diff --git a/refs.h b/refs.h
index 5075073..bf96b36 100644
--- a/refs.h
+++ b/refs.h
@@ -337,6 +337,7 @@ int transaction_delete_ref(struct transaction
*transaction,
/*
* Append a reflog entry for refname. If the REFLOG_TRUNCATE flag is set
* this update will first truncate the reflog before writing the entry.
+ * If msg is NULL no update will be written to the log.
*/
int transaction_update_reflog(struct transaction *transaction,
const char *refname,
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Announce] Availability of a Java based Subversion to Git conversion program with automatic (and pluggable) branch detection for whole repository conversions
Hello, For the past 8 months I've been working on the process and tooling to convert the Kuali Student subversion repository into Git and to support CI on pull requests with auto merge to trunk once the builds were green and the appropriate sign-off provided. The Kuali Student project is being restructured so my work on CI was halted but I was able to get the repository converted and placed into Github: https://github.com/kuali-student/archived-from-svn (Contains Revisions r1 through r77740 in 20,631 branches and 95,297 git commits) This work is not being officially supported by the Kuali Foundation in the future but I'm personally interested in seeing other projects use it to convert from Subversion into Git (and find any edge cases it might not be handling correctly right now) Since our conversion was successful I wanted to alert users on both the Git and JGit mailing lists about the Java based conversion program that I wrote to perform the conversion. The code and some cursory instructions on how to use it are located here: https://github.com/kuali-student/git-repository-tools, the current version can be downloaded from maven central: http://search.maven.org/#artifactdetails|org.kuali.student.repository|git-importer|0.0.4|jar It is intended for larger repositories like kuali student with around 100,000 or more revisions with many product streams and questionable at times branch naming strategies; instead of enumerating which branches you want this conversion program will extract everything. You can specify a per repository branch detection strategy to handle non-standard cases so that looking back in the history things will make more sense, but it shouldn't be needed to get an accurate repository. Key features: . Full repository conversion by parsing Subversion version 2 dump streams and writing into a bare Git repository. . Automatic branch detection o We figure out how to split the full path to a blob into a branch part and file part. The branch part becomes the name of the branch and the file part turns into the Tree object of the commit. o We track copy-from information similar I think to how git-svn does so that for each subversion revision we have a list of all of the git branches and their heads at that point in time. o We convert everything but if the branch naming is non-standard you can have branches created with subdirectories that really should have been separate branches themselves. . Plugin Mechanism to define custom per repository branch detection (before falling back on the standard mechanisms) o See how the student-plugin(https://github.com/kuali-student/git-repository-tools/tree/master/git-importer-student-plugin) was setup with its own custom branch detection logic (lots of conversion iterations in that scheme) o Also look at how unit testing can be done on the repository specific branch scenarios. . Fusion instead of submodules for svn:externals o The fusion-maven-plugin was created and its fuse mojo will do essentially a multi subtree merge to turn the aggregate branch (the one where the svn:externals property was set) into a commit whose tree contains actual materialized subdirectories with the tree of the module branch placed within it. o The git-importer would leave fusion-maven-plugin.dat files in the root of the commit tree's where in svn there had been svn:externals set so that this fusion process could be applied at a later point in time. . Fairly fast o Creating the subversion mirror and dump files can take some time o The KS svn repository mirror was 8.8 GB but that turned into about 20 GB using bzip2 compressed subversion version 2 dump streams o Running against the existing dump files it would take the importer about 12 hours to perform the full conversion on a low end core 2 duo (3Ghz) writing on a raid-0 7200 RPM disk drive. . Accurate o I compared our key release tags and development branches by doing an subversion export of the particular equivalent of the git branch (based on the path and revision in the comment) and added into git and then did a git diff to make sure there are no differences (and when I found differences I tracked them down and added unit tests to reproduce and fixed them). Additional Cleanup Programs: The git-repository-tools repository also includes the cleanup programs we used https://github.com/kuali-student/git-repository-tools/tree/master/git-repo-cleaner: Our initial converted repo was 2.8 GB (final was 1.3 GB) so we looked at splitting the graph based on date and then using git grafts to give developers the full history. The splitting program would find the split point and write a grafts file for later use. But we found out that a certain kind of database file was taking up a lot of space (over 50% of the converted repository) so instead of splitting we did three cleanup operations: 1. Remove the content of all .mpx database files (sql files built a db which
[BUG] Possible issue with word-diff option
Hi,
I'm currently developing a local web based GUI for git in the same
fashion as mercurial's 'hg serve': git-webui
(https://github.com/alberthier/git-webui)
I tried to add word-diff highlighting in my diff visualization panels.
I used the '--word-diff=porcelain' option of 'git show' and 'git
diff'.
Unfortunately I ran into an issue so I want to make sure I understand
properly the format
Here is how I interpret this output:
- A line of the diff no longer corresponds to a line in the source
file. A line of the source file, is represented between two leading
'~' markers
- A line starting with a '+' or '-' is respectively an added or
removed line fragment
- A line starting with a ' ' (space) is an unchanged line fragment
The problem is visible with the git-webui repository itself:
git clone https://github.com/alberthier/git-webui
git show --word-diff=porcelain ed934a7# This is the head
of the 'word-diff' branch
# search for the first occurrence of 'fragment'
In the source code, several lines have been replaced with the
following single line:
var fragment = line.substr(1);
But in the diff, 'fragment' and 'line.substr(1);' don't apprear in the
same '~' block.
I get:
~
var
-pre
+fragment
=
-$('pre class=diff-view-line').appendTo(view)[0];
~
[ some removed lines]
~
-}
+line.substr(1);
~
By reading this output, it looks like 'var fragment = ' and
'line.substr(1);' aren't on the same line.
I would have expected:
~
var
-pre
+fragment
=
-$('pre class=diff-view-line').appendTo(view)[0];
+line.substr(1);
~
[ some removed lines]
Is there something I miss or is this a bug of git's word-diff algorithm ?
Regards,
Eric
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/15] refs.c: allow multiple reflog updates during a single transaction
Ronnie Sahlberg sahlb...@google.com writes:
@@ -3531,7 +3537,7 @@ struct ref_update {
enum transaction_update_type update_type;
unsigned char new_sha1[20];
unsigned char old_sha1[20];
- int flags; /* REF_NODEREF? */
+ int flags; /* REF_NODEREF? or private flags */
Not a very informative comment, I'd have to say. How are users of
this API expected to avoid stepping on each others' and API
implementation's toes?
@@ -3539,8 +3545,9 @@ struct ref_update {
/* used by reflog updates */
int reflog_fd;
- struct lock_file reflog_lock;
+ struct lock_file *reflog_lock;
What is this change about?
Does the lifetime rule for struct lock_file described in
Documentation/technical/api-lockfile.txt, namely, once you call
hold_lock_file_* family on it, you cannot free it yourself, have
any implication on this?
+ if (!(update-flags UPDATE_REFLOG_NOLOCK))
+ update-reflog_lock = xcalloc(1, sizeof(struct lock_file));
+
Hmph, does this mean that the caller needs to keep track of the refs
it ever touched inside a single transaction, call this without nolock
on the first invocation on a particular ref and with nolock on the
subsequent invocation?
Or is the caller just implementation detail of the API and higher level
callers do not have to care?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Incorrect documention for git-credential-store
The man page for git-credential-store at http://git-scm.com/docs/git-credential-store and https://www.kernel.org/pub/software/scm/git/docs/git-credential-store.html incorrectly state that the option to change the credential storage path is '--store'. The name of the option should be '--file'. I have noticed this running it 1.8.5.3 Regards - Jesse -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-gui/gitk: Do not depend on Cygwin's kill command on Windows
Windows does not necessarily mean Cygwin, it could also be MSYS. The
latter ships with a version of kill that does not understand -f. In
msysgit this was addressed shipping Cygwin's version of kill.
Properly fix this by using the stock Windows taskkill command instead,
which is available since Windows XP Professional.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
git-gui/git-gui.sh | 4 +---
gitk-git/gitk | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index b186329..a1c823e 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -666,9 +666,7 @@ proc kill_file_process {fd} {
catch {
if {[is_Windows]} {
- # Use a Cygwin-specific flag to allow killing
- # native Windows processes
- exec kill -f $process
+ exec taskkill /pid $process
} else {
exec kill $process
}
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 3520bda..bfc5cfa 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -445,7 +445,7 @@ proc stop_instance {inst} {
set pid [pid $fd]
if {$::tcl_platform(platform) eq {windows}} {
- exec kill -f $pid
+ exec taskkill /pid $pid
} else {
exec kill $pid
}
--
1.8.4-mingw-3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Possible issue with word-diff option
I forgot to mention the version :
I tested with Ubuntu's git 1.9.1 and a 2.1.0 version I built myself
2014-10-23 20:54 GMT+02:00 Éric Alber eric.al...@gmail.com:
Hi,
I'm currently developing a local web based GUI for git in the same
fashion as mercurial's 'hg serve': git-webui
(https://github.com/alberthier/git-webui)
I tried to add word-diff highlighting in my diff visualization panels.
I used the '--word-diff=porcelain' option of 'git show' and 'git
diff'.
Unfortunately I ran into an issue so I want to make sure I understand
properly the format
Here is how I interpret this output:
- A line of the diff no longer corresponds to a line in the source
file. A line of the source file, is represented between two leading
'~' markers
- A line starting with a '+' or '-' is respectively an added or
removed line fragment
- A line starting with a ' ' (space) is an unchanged line fragment
The problem is visible with the git-webui repository itself:
git clone https://github.com/alberthier/git-webui
git show --word-diff=porcelain ed934a7# This is the head
of the 'word-diff' branch
# search for the first occurrence of 'fragment'
In the source code, several lines have been replaced with the
following single line:
var fragment = line.substr(1);
But in the diff, 'fragment' and 'line.substr(1);' don't apprear in the
same '~' block.
I get:
~
var
-pre
+fragment
=
-$('pre class=diff-view-line').appendTo(view)[0];
~
[ some removed lines]
~
-}
+line.substr(1);
~
By reading this output, it looks like 'var fragment = ' and
'line.substr(1);' aren't on the same line.
I would have expected:
~
var
-pre
+fragment
=
-$('pre class=diff-view-line').appendTo(view)[0];
+line.substr(1);
~
[ some removed lines]
Is there something I miss or is this a bug of git's word-diff algorithm ?
Regards,
Eric
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: squash commits deep down in history
Am 23.10.2014 um 14:34 schrieb Henning Moll: i need to squash several commits into a single one in a automated way. I know that there is interactive rebase, which can also be automated using GIT_SEQUENCE_EDITOR. Unfortunately my history is very large and i need to squash deep down in the history several times. So using interactive rebase seems not to be the right tool. I wonder if i can solve this task using filter-branch? I have a file that list the SHA1s for each squash operation per line. All SHA1s of a line are in chronological order (youngest to oldest), or in other words: the first SHA1 is the child of the second, and so on. Use git-replace do construct a squashed commit that replaces the last child in each run such that its parent points to the parent of the first in the run. Then use a git-filterbranch without filters to burn the parenthood into the history. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
life cycle documentation
Greetings, I am unable to find any documentation regarding the life cycle regarding the various versions of git. Is only the current version supported? What about older minor/major versions? At what point does a version go EOL? Currently, is only 2.1.2 supported? I would entertain the thought on creating a RELEASES document if the information is provided. Ben Harper OS Deployment Services, RPMDEV Rackspace Hosting IUS Community -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: squash commits deep down in history
Am 23.10.2014 um 22:08 schrieb Johannes Sixt: Use git-replace do construct a squashed commit that replaces the last child in each run such that its parent points to the parent of the first in the run. Then use a git-filterbranch without filters to burn the parenthood into the history. -- Hannes Wow, cool. Thanks a lot for the hint. I managed to do the following: Suppose i have the following history A - B - C - D -master and i want to squash B and C together. First i create a temporary branch on A and switch to it. Then i cherry-pick B and C without commit. So all the changes are merged into the index. Then i commit a single commit M. The history now looks like M -temp / A - B - C - D -master Using $ git replace C M leads to temp | v A - M - D -master As far as i understand, such a repalce is something like a symbolic link. Is that right? This is interesting: Before filter-branch, the deletion of the replace would lead to the initial situation (ABCD). After filter-branch, the history is (AM'D'). The replace still exists but is now something like a dead link. I may come to life again after git resetting to somewhere before filter-branch. Even before creating the replace (the replace ref itself is not part of the history). Even if you gor before creation of M: The link still works as long as M is not garbage collected. I was very irritated after resetting to where i commited D, and still seeing A-M-D. Somehow logical, somehow crazy! I am still a git learner ;-) Two questions remain for me: 1. Is there a more elegant way to build M? 2. Having a replace in place before filter-branch: Is there a way to find out what the replace is hiding? A simple git log C produces M-A. How to get C-B-A? Best regards Henning -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] receive-pack.c: mark file local symbols as static
Commit 8796e182 (receive-pack.c: use a single transaction when
atomic-push is negotiated, 21-10-2014) added the 'transaction'
and 'err' variables as external symbols.
Noticed by sparse. ('err' was not declared. Should it be static?)
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi Ronnie,
If you need to re-roll your 'rs/ref-transaction-send-pack' branch, could
you please squash this into the re-rolled version of commit 8796e182.
Thanks!
ATB,
Ramsay Jones
builtin/receive-pack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 030698c..7f6d814 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -68,8 +68,8 @@ static const char *NONCE_SLOP = SLOP;
static const char *nonce_status;
static long nonce_stamp_slop;
static unsigned long nonce_stamp_slop_limit;
-struct strbuf err = STRBUF_INIT;
-struct transaction *transaction;
+static struct strbuf err = STRBUF_INIT;
+static struct transaction *transaction;
static enum deny_action parse_deny_action(const char *var, const char *value)
{
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Guten Tag und Gott segne Sie.
Guten Tag und Gott segne Sie. Mein Name ist Frau Rose Wenger, ein Kaufmann in Dubai, in den Vereinigten Arabischen Emiraten Ich habe mit Ösophagus-Krebs diagnostiziert worden. Es hat alle Formen der medizinischen Behandlung besudelt, und im Moment habe ich nur über ein paar Monate zu leben, nach medizinischen Experten. Ich habe beschlossen, spenden die meisten von meinem Geld für wohltätige Zwecke Organisationen, ich habe Geld, um einige Charity-Organisationen in den Vereinigten Arabischen Emiraten, Algerien, Liberia und Malaysia verteilt. Jetzt, da meine Gesundheit so schlecht verschlechtert hat, kann ich nicht mehr ich selbst tun. Der letzte von meinem Geld, das niemand kennt ist die riesige Kaution von fünfzehn Millionen Dollar $ 15.000.000, dass ich mit einem Finanzierungs / Security Company im Ausland. Ich möchte, dass Sie mir helfen, sammeln diese Hinterlegung und versendet sie an karitative Einrichtungen. Ich habe neben 60% für Sie für Ihre Zeit gesetzt und teilen 40% für Wohltätigkeitsorganisationen in Europa. Ich werde, sobald ich von Ihnen und Ihrer Bereitschaft, diese Aufgabe für mich eingegangen geben Ihnen einen direkten Kontakt der mein Anwalt. E-Mail: rose.wenge...@gmail.com Bleiben im Namen des Herrn gesegnet. Frau Rose Wenger -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] diff -B -M: fix output for copy and then rewrite case
Starting from a single file, A, if you create B as a copy of A (and
possibly make some edit) and then make extensive change to A, you
will see:
$ git diff -C --name-status
C89AB
M A
which is expected. However, if you ask the same question in a
different way, you see this:
$ git diff -B -M --name-status
R89AB
M100 A
telling us that A was rename-edited into B (as if A will no longer
exist as the result) and at the same time A itself was extensively
edited.
In this case, because the resulting tree still does have file A
(even if it has contents vastly different from the original), we
should use Copy, not Rename, to avoid hinting that A somehow
goes away.
Two existing tests were depending on the wrong behaviour, and fixed.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diffcore-break.c | 7 +++
t/t4008-diff-break-rewrite.sh | 4 ++--
t/t4023-diff-rename-typechange.sh | 3 ++-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index 1d9e530..5473493 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -246,6 +246,13 @@ static void merge_broken(struct diff_filepair *p,
dp = diff_queue(outq, d-one, c-two);
dp-score = p-score;
+ /*
+* We will be one extra user of the same src side of the
+* broken pair, if it was used as the rename source for other
+* paths elsewhere. Increment to mark that the path stays
+* in the resulting tree.
+*/
+ d-one-rename_used++;
diff_free_filespec_data(d-two);
diff_free_filespec_data(c-one);
free(d);
diff --git a/t/t4008-diff-break-rewrite.sh b/t/t4008-diff-break-rewrite.sh
index 27e98a8..8920464 100755
--- a/t/t4008-diff-break-rewrite.sh
+++ b/t/t4008-diff-break-rewrite.sh
@@ -123,10 +123,10 @@ test_expect_success \
'git diff-index -B -M $tree current'
# file0 changed from regular to symlink. file1 is very close to the preimage
of file0.
-# because we break file0, file1 can become a rename of it.
+# the change does not make file0 disappear, so file1 is denoted as a copy of
file0
cat expected \EOF
:100644 12 f5deac7be59e7eeab8657fd9ae706fd6a57daed2
67be421f88824578857624f7b3dc75e99a8a1481 T file0
-:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3
f5deac7be59e7eeab8657fd9ae706fd6a57daed2 R file0 file1
+:100644 100644 6ff87c4664981e4397625791c8ea3bbb5f2279a3
f5deac7be59e7eeab8657fd9ae706fd6a57daed2 C file0 file1
EOF
test_expect_success \
diff --git a/t/t4023-diff-rename-typechange.sh
b/t/t4023-diff-rename-typechange.sh
index 55d549f..8c98237 100755
--- a/t/t4023-diff-rename-typechange.sh
+++ b/t/t4023-diff-rename-typechange.sh
@@ -76,7 +76,8 @@ test_expect_success 'moves and renames' '
git diff-tree three four -r --name-status -B -M | sort actual
{
- echo R100 foo bar
+ # see -B -M (#6) in t4008
+ echo C100 foo bar
echo T100 foo
} | sort expect
test_cmp expect actual
--
2.1.2-595-g1568c45
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug Report: Submodule conflict error message
In a project with a submodule, if you merge two diverging branches in which one branch updated which commit the submodule points to, and the other branch moves the submodule to a new location, the resulting merge error message does not provide information about what the conflict was, or the path to the conflicted directory. I've attached a short script which sets up a project with a submodule and creates both branches. If after running it you cd into 'top-level-project' and run 'git merge branch_that_points_the_submodule_to_new_commit' the resulting error message is: Auto-merging submodule-moved Adding as submodule-moved~HEAD instead Automatic merge failed; fix conflicts and then commit the result. I would have expected an output in line with other merge conflict messages. Something with the format: CONFLICT (REASON): Merge conflict in PATH_TO_CONFLICT Where REASON would be something like (delete/modify) I believe this might be a bug in the implementation. Thank you submodule-conflict.sh Description: Bourne shell script
jpalac...@atlassian.com
In a project with a submodule, if you merge two diverging branches in which one branch updated which commit the submodule points to, and the other branch moves the submodule to a new location, the resulting merge error message does not provide information about what the conflict was, or the path to the conflicted directory. I've included at the bottom a short script which sets up a project with a submodule and creates both branches. If after running it you cd into 'top-level-project' and run 'git merge branch_that_points_the_submodule_to_new_commit' the resulting error message is: Auto-merging submodule-moved Adding as submodule-moved~HEAD instead Automatic merge failed; fix conflicts and then commit the result. I would have expected an output in line with other merge conflict messages. Something with the format: CONFLICT (REASON): Merge conflict in PATH_TO_CONFLICT Where REASON would be something like (delete/modify) I believe this might be a bug in the implementation. Thank you -- # Create a submodule mkdir submodule pushd submodule echo This is a submodule README.txt git init git add README.txt git commit -m Initial commit popd # Create a top level project mkdir top-level-project pushd top-level-project echo This is a parent project README.txt git init git add README.txt git commit -m Initial commit # Add submodule to top level project git submodule add ../submodule/ git commit -m Added a submodule # Create two diverging branches git checkout -b branch_that_points_the_submodule_to_new_commit git checkout -b branch_that_moves_the_submodule_to_new_path # Update the commit the submodule points to in one branch git checkout branch_that_points_the_submodule_to_new_commit pushd submodule echo This modifies the README file README.txt git add . git commit -m Added line to README file popd git add submodule git commit -m Updated submodule to point to new commit # Move the submodule directory in the other branch git checkout branch_that_moves_the_submodule_to_new_path git submodule update git mv submodule submodule-moved git commit -m Moved submodule to new path -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
